PGI User Forum
 SearchSearch   MemberlistMemberlist     RegisterRegister   ProfileProfile    Log inLog in 

CUDA-x86.

Loop unrolling (PGI 5.1 and 5.2: pgf77)
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling
View previous topic :: View next topic  
Author Message
mkrech



Joined: 15 Oct 2004
Posts: 11

PostPosted: Wed May 18, 2005 8:44 am    Post subject: Reply with quote

Hi Mat,

Today I got the information, that on Pentiums the aforementioned user program
works fine (5.2 and 6.0). So the trouble is restricted to Opteron platforms. Do you
have an explanation for this?

Best regards,
Michael
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5815
Location: The Portland Group Inc.

PostPosted: Wed May 18, 2005 10:53 am    Post subject: Reply with quote

Have the user compile and run the program with the following options. Let me know which get the expected answer.

On the P4,
1) -fast -Kieee -pc 64 <- don't accumulate values in 80-bit x87 FPU registers
2) -fast -Mscalarsse <- Use SSE instead of x87
If either of these fail there it's a x87 vs SSE precission issue.

On the Opteron:
1) -fast -tp k8-32 <- Should be the same as -fast -Mscalarsse on the P4
2) -O0 <- If it fails here then its a 64-bit porting issue
3) -O2
4) -O2 -Munroll=c:1
5) -O2 -Munroll=c:1 -Mlre
6) -fast

- Mat
Back to top
View user's profile
mkrech



Joined: 15 Oct 2004
Posts: 11

PostPosted: Mon May 23, 2005 8:22 am    Post subject: Reply with quote

Hi Mat,

Here are the results:

Pentium 4:
1) -fast -Kieee -pc 64
2) -fast -Mscalarsse
3) -O0
OK in all cases (correct result).

Opteron:
1) -fast -tp k8-32
could not be tested due to some numerical libraries, which are only available in 64 bit
2) -O0
pgi 5.2: the same as on P4
pgi 6.0: segmentation fault
3) -O2
4) -O2 -Munroll=c:1
5) -O2 -Munroll=c:1 -Mlre
pgi 5.2 & pgi 6.0: "wrong" result, but consistent among one another
6) -fast
pgi 5.2 & pgi 6.0: the same as on P4

The last result surprises me. However, the tests were made for an untypically small
system (i.e., some arrays may not run out of their assumed bounds). I hope that
the results 2)-5) on the Opteron tell you something.

Many thanks and best regards,
Michael
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5815
Location: The Portland Group Inc.

PostPosted: Mon May 23, 2005 10:31 am    Post subject: Reply with quote

Hi Michael,

Although I'm just speculating, it seems the program might be reading undefined memory. I've seen programs that have an 'off by one' error where the program was reading off the end of an array. Most of the time the program was lucky and the memory it was accessing was a valid location. However, changes in the compiler flags, compiler version, and/or platform can effect how the memory is laid out and result in unexpected behavior.

The next step is to determine why the program seg faults using "-O0" and the 6.0 PGI compilers in 64-bit. First add "-Mbounds" to see if your reading off the end of an array. Next compile and run with "-g". If the program still seg faults use pgdbg or gdb to isolated where and why its seg faulting. "-g" can change the memory layout so the program might succeed. If this occurs, run the "-O0" compiled program through pgdbg. You wont have the debug symbol information but at least you can get the file name and line number where the seg fault occurs.

- Mat
Back to top
View user's profile
mkrech



Joined: 15 Oct 2004
Posts: 11

PostPosted: Mon May 30, 2005 9:51 am    Post subject: Reply with quote

Dear Mat,

We have identified the source of the error (the program works with -g). The
cause is the value of an interger index, which is overwritten on the second
call to a subroutine by a meaningless value. The subroutine apparently
accesses memory bejond its allowed range when called a second time!
The integer index was passed to the subroutine as an additional parameter
to allow its value to be printed. The principal code structure is:

subroutine amix(..., t, n, ..., index)
integer n, index
double precision t(n), temp1, temp2
...
do i = 1, n ! n = 1 here
...
temp1 = ...
temp2 = ...
...
print *, index ! value OK
t(i) = temp2 - temp1
print *, index ! meanigless value on second call
...
end do
...
end subroutine amix

The first call to amix leaves 'index' unchanged, the second call changes 'index' to
something meaningless (e.g. a large negative integer) which causes the program
to seg fault, when 'index' used to address another array. Apart from the 'print'
statements the subroutine does not access 'index' and therefore index is normally
omitted from the parameter list. Nonetheless 'index' is corrupted after the second
call to the subroutine.

For me this seems to point to a compiler problem on 64 bit opteron systems.

Best regards,
Michael
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling All times are GMT - 7 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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 © phpBB Group