Any danger in this sample program?
in [Fortran]
|
Prev: Atarax cheapest. Lowest prices for Atarax online. Atarax how much can you take. Next day delivery on Atarax saturday.
Next: Buy online HYDROCODONE, order prescription free HYDROCODONE, cheap HYDROCODONE next day
From: yaqi on 28 Apr 2010 14:24 On Apr 28, 12:03 pm, yaqi <yaqiw...(a)gmail.com> wrote: > Hi Steve, > > Many thanks! And sorry I am too confident and not test the sample > program I attached here. > > The problem is that the actual code is so large and propertery that I > am sure no one want to really look into it. > > I add few print statements in my actual code at the beginning of > rename and after. Something like: > SUBROUTINE rename(a, b) > IMPLICIT NONE > TYPE(mytype) :: a > TYPE(mytype) :: b > print *, associated(a%ptr), associated(b%ptr), size(a%ptr), size(b > %ptr) > b%ptr => a%ptr > NULLIFY(a%ptr) > print *, associated(a%ptr), associated(b%ptr), size(a%ptr), size(b > %ptr) > RETURN > END SUBROUTINE rename > > And I saw the second print did not give me the expected output. > Although a%ptr is not associated, its size is not zero. (I guess it is > not specified in the Fortran reference.) This is tolerable. On the > other hand, b%ptr is associated but its size is not equal to the size > of a%ptr in the first print statement. It gave me 1! If I run the code > under Debug mode, everything is just fine. > > I am sorry I can not provide the actual code. > > On Apr 28, 11:43 am, Steve Lionel <steve.lio...(a)intel.invalid> wrote: > > > > > On 4/28/2010 1:18 PM, yaqi wrote: > > > > MODULE mytype > > snip... > > > > I have a large code doing the similar thing. And when I turn O3 on > > > with Intel Visual Fortran compiler. The code crashes and I am pretty > > > sure it is the 'rename' subroutine that causes the problem. But I did > > > not see anything wrong in it. Is there any danger in 'rename' which is > > > not so obvious? > > > It is evident that you retyped in the code as you showed it here, as it > > has several syntax errors. When I correct the syntax errors and build > > it with /O3 and Intel Visual Fortran 11.1.054 (and 11.1.065), it runs fine. > > > I conclude, then, that the code you showed here is not representative of > > your actual code. Paraphrases and uncompilable excerpts do not help in > > getting your problem resolved. Please provide an actual test case. I'd > > also recommend that you take this to our user forum athttp://software.intel.com/en-us/forums/intel-visual-fortran-compiler-... > > where we can help you better. > > > -- > > Steve Lionel > > Developer Products Division > > Intel Corporation > > Nashua, NH > > > For email address, replace "invalid" with "com" > > > User communities for Intel Software Development Products > > http://software.intel.com/en-us/forums/ > > Intel Software Development Products Support > > http://software.intel.com/sites/support/ > > My Fortran blog > > http://www.intel.com/software/drfortran- Hide quoted text - > > - Show quoted text - I am also pretty frustrated because of the problem. I can not reproduce it in the test problem too. I can do the similar thing to 'rename' with 'copy(a,b) + delete(a)'. But it is really not necessary.
From: Jim Xia on 28 Apr 2010 15:09 If you can't show us the full code, then take a look at the "restrictions on entities associated with dummy arguments" subclause in standard to see if you've done anything violating the rules. The following is the latest text from N1828. " While an entity is associated with a dummy argument, the following restrictions hold. (1) Action that a ects the allocation status of the entity or a subobject thereof shall be taken through the dummy argument. (2) If the allocation status of the entity or a subobject thereof is a ected through the dummy argument, then at any time during the invocation and execution of the procedure, either before or after the allocation or deallocation, it shall be referenced only through the dummy argument. (3) Action that a ects the value of the entity or any subobject of it shall be taken only through the dummy argument unless (a) the dummy argument has the POINTER attribute or (b) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT (IN), the dummy argument is a scalar object or an assumed-shape array without the CONTI- GUOUS attribute, and the actual argument is a target other than an array section with a vector subscript. (4) If the value of the entity or any subobject of it is a ected through the dummy argument, then at any time during the invocation and execution of the procedure, either before or after the de nition, it may be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute or (b) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT (IN), the dummy argument is a scalar object or an assumed-shape array without the CONTI- GUOUS attribute, and the actual argument is a target other than an array section with a vector subscript." I'm suspecting you have something directly violates the rules. The problems are normally ONLY exposed when you turn on high optimizations. And of course, you may also be looking at a compiler bug. Cheers, Jim
From: yaqi on 28 Apr 2010 15:21 On Apr 28, 1:09 pm, Jim Xia <jim...(a)hotmail.com> wrote: > If you can't show us the full code, then take a look at the > "restrictions on entities associated with dummy arguments" subclause > in standard to see if you've done anything violating the rules. The > following is the latest text from N1828. > > " > While an entity is associated with a dummy argument, the following > restrictions hold. > (1) Action that a ects the allocation status of the entity or a > subobject thereof shall be taken through > the dummy argument. > (2) If the allocation status of the entity or a subobject thereof is a > ected through the dummy argument, > then at any time during the invocation and execution of the procedure, > either before or after the > allocation or deallocation, it shall be referenced only through the > dummy argument. > (3) Action that a ects the value of the entity or any subobject of it > shall be taken only through the > dummy argument unless > (a) the dummy argument has the POINTER attribute or > (b) the dummy argument has the TARGET attribute, the dummy argument > does not have INTENT > (IN), the dummy argument is a scalar object or an assumed-shape array > without the CONTI- > GUOUS attribute, and the actual argument is a target other than an > array section with a > vector subscript. > (4) If the value of the entity or any subobject of it is a ected > through the dummy argument, then at > any time during the invocation and execution of the procedure, either > before or after the de nition, > it may be referenced only through that dummy argument unless > (a) the dummy argument has the POINTER attribute or > (b) the dummy argument has the TARGET attribute, the dummy argument > does not have INTENT > (IN), the dummy argument is a scalar object or an assumed-shape array > without the CONTI- > GUOUS attribute, and the actual argument is a target other than an > array section with a > vector subscript." > > I'm suspecting you have something directly violates the rules. The > problems are normally ONLY exposed when you turn on high > optimizations. > > And of course, you may also be looking at a compiler bug. > > Cheers, > > Jim Thanks Jim, it is very informative. There is a copy-paste issue in the text, can you give me a link where I can find N1828? Many thanks.
From: Richard Maine on 28 Apr 2010 15:38 yaqi <yaqiwang(a)gmail.com> wrote: > Although a%ptr is not associated, its size is not zero. (I guess it is > not specified in the Fortran reference.) "Not specified" is a bit shy of the mark. It is far worse than that. The Fortran standard does specify some related things, but the specifications are in the opposite direction of what you appear to be thinking. They are also very much the kinds of things that it is critical to understand when working with pointers. Pointers are tricky. If you don't understand them *VERY* well, you are highly likely to introduce subtle bugs. First, if a pointer is not associated, the standard specifies that it is illegal for your program to even inquire about the size. If you do so, then anything can happen; certainly it could return random bogus values; it could also abort with an error message. Both of those possibilities are very real. It could also cause subtle symptoms that show up elsewhere, though that doesn't seem as likely for the case of inquiring about size (unless you mistakenly believe the result and index out of bounds as a result). Perhaps even more important is that you need to understand that a pointer can have one of *3* association statuses. It can be associated, not associated, or have undefined association status. You canot use the associated intrinsic (or anything else) to tell whether a pointer is associated. That may sound odd, but it is so and it is very important. In particular, it is illegal to even use the associated intrinsic on a pointer whose association status is undefined. If you do so, then, as before, you might get bogus results, an error result, or subtle symptoms elsewhere. The associated intrinsic is useful only to distinguish between associated and not associated, and only if you have separately ruled out the possibility of the ssociation status being undefined. That's why I say it can't tell you wehther a pointer is associated - because it can't distinguish between associated and undefined. If you use the associated intrinsic on something that has undefined association status, and you then take actions based on the assumption that it returns a meaningful result, it is very easy to corrupt memory and cause all kinds of symptoms, possibly in places far removed from where the error was made. And yes, the symptoms can change depending on almost anything. That certainly includes running in debug versus non-debug mode. To determine whether a pointer has undefined association status - there is no intrinsic for that. The only way to do it is to understand and watch for all the ways that the standard says a pointer can get undefined association status. No, that's not easy. It is part of why pointers are tricky. I don't have any direct evidence that this is related to your problem. I don't have direct evidence of much of anything. But your posting seems to illustrate inadequate appreciation of these issues, which naturally makes me suspicious of them. The bugs they cause can be very subtle. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: yaqi on 28 Apr 2010 15:44
On Apr 28, 1:09 pm, Jim Xia <jim...(a)hotmail.com> wrote: > If you can't show us the full code, then take a look at the > "restrictions on entities associated with dummy arguments" subclause > in standard to see if you've done anything violating the rules. The > following is the latest text from N1828. > > " > While an entity is associated with a dummy argument, the following > restrictions hold. > (1) Action that a ects the allocation status of the entity or a > subobject thereof shall be taken through > the dummy argument. > (2) If the allocation status of the entity or a subobject thereof is a > ected through the dummy argument, > then at any time during the invocation and execution of the procedure, > either before or after the > allocation or deallocation, it shall be referenced only through the > dummy argument. > (3) Action that a ects the value of the entity or any subobject of it > shall be taken only through the > dummy argument unless > (a) the dummy argument has the POINTER attribute or > (b) the dummy argument has the TARGET attribute, the dummy argument > does not have INTENT > (IN), the dummy argument is a scalar object or an assumed-shape array > without the CONTI- > GUOUS attribute, and the actual argument is a target other than an > array section with a > vector subscript. > (4) If the value of the entity or any subobject of it is a ected > through the dummy argument, then at > any time during the invocation and execution of the procedure, either > before or after the de nition, > it may be referenced only through that dummy argument unless > (a) the dummy argument has the POINTER attribute or > (b) the dummy argument has the TARGET attribute, the dummy argument > does not have INTENT > (IN), the dummy argument is a scalar object or an assumed-shape array > without the CONTI- > GUOUS attribute, and the actual argument is a target other than an > array section with a > vector subscript." > > I'm suspecting you have something directly violates the rules. The > problems are normally ONLY exposed when you turn on high > optimizations. > > And of course, you may also be looking at a compiler bug. > > Cheers, > > Jim If I understand correctly, I can not vaolate these rules because the module here is like a class definition in c++. There are no data in the module. The caller pass the arguments to the rename subroutine, the rename subroutine can only see the passed arguments and does operations over the arguments. Although I really donot want to, I suspect this is a compiler bug because I print the size of b right after the pointer assignment but it is not equal to the size of a in my real code. |