Maybe in the 32-bit compile, a value is stored in a 64-bit register,
and when it gets "robbed" (to populate the missing value for an
adjacent variable) the 32 bits of backfill are taken, so the remaining
value is good; but in a 64-bit compile, all 64 bits are taken so the
remaininder is rubbish. It would depend on both the compiler and the
hardware, and the takeaway is to not do that :-)<br>
Peter<br><br><div><span class="gmail_quote">On 8/6/08, <b class="gmail_sendername">Gus Correa</b> <<a href="mailto:gus@ldeo.columbia.edu">gus@ldeo.columbia.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Ricardo, David, Mark, and list<br>
<br>
If as Ricardo says, he suppressed the 5th parameter ("use_work") on the call<br>
to rfftwnd_f77_mpi, which has 6 parameters, wouldn't it start mismatching pointers<br>
on the 5th parameter, instead of on the 2nd parameter ("n_fields")?<br>
I.e. "use_work" would take the value of "FFTW_NORMAL_ORDER",<br>
and "FFTW_NORMAL_ORDER" would get a random value (OS permitting),<br>
but the initial 4 parameters would be correct, right?<br>
In any case, there is little difference between this and what David said,<br>
the point of failure is different, the nature is the same.<br>
<br>
However, it is interesting that somehow<br>
at runtime the program segfaults in 64-bits, but doesn't fail in 32-bits,<br>
although it most likely computes wrong stuff.<br>
Ricardo have you ever QCd' the 32-bit output before you fixed/inserted "use_work"?<br>
If you were in a big lucky strike the random value left on the FFTW_NORMAL_ORDER<br>
address matched your needs, and the result may be correct! :)<br>
<br>
Anyway, somehow the program seems to behave differently,<br>
with the OS superego being more compliant (in a nasty sense) in 32-bits than it is in 64-bits.<br>
Does the OS paradoxically give less memory room for the stack in 64-bits, leading to the segfault?<br>
Or does it give the same room, but because the pointers are bigger the segfault is more likely?<br>
Or does the segfault happen somewhere else, not on the stack?<br>
Where?<br>
Why in 64-bits?<br>
Why not in 32 bits?<br>
<br>
Yes, as David noted about programming, here I also got and continue to get these bugs,<br>
particularly in Fortran programs where no parameter checking is enforced.<br>
And the nastier ones are those that don't segfault,<br>
then come back to haunt you when somebody looks at the output,<br>
if you are not careful enough to look at it before anybody else does.<br>
<br>
Cheers,<br>
Gus Correa<br>
<br>
Compilar e' preciso,<br>
rodar e' impreciso!<br>
<br>
... mais uma do vosso alter-ego P'ssoa ... :)<span class="q"><br>
<br>
-- <br>
---------------------------------------------------------------------<br>
Gustavo J. Ponce Correa, PhD - Email: <a href="mailto:gus@ldeo.columbia.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gus@ldeo.columbia.edu</a><br>
Lamont-Doherty Earth Observatory - Columbia University<br>
P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA<br>
---------------------------------------------------------------------<br>
<br>
<br></span><div><span class="e" id="q_11b9b18d7dfa9724_2">
Lombard, David N wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Aug 05, 2008 at 02:57:42AM -0700, Ricardo Reis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 4 Aug 2008, Mark Kosmowski wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, why did the 32-bit test case work? Shouldn't the same problem<br>
crash both systems if it is a code issue?<br>
<br>
</blockquote></blockquote>
<br>
Not necessarily given the error described below.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I asked the same question myself... The function interface is:<br>
<br>
call rfftwnd_f77_mpi(plan_c2r, &<br>
1, local_data, work, use_work, FFTW_NORMAL_ORDER)<br>
<br>
where use_work is an integer, value 1 if you use the work temporary<br>
array, 0 otherwise. This was the variable I wasn't passing.<br>
<br>
</blockquote>
...<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The wrapper function for this is (from rfftw_f77_mpi.c):<br>
<br>
void F77_FUNC_(rfftwnd_f77_mpi,RFFTWND_F77_MPI)<br>
(rfftwnd_mpi_plan *p, int *n_fields, fftw_real *local_data,<br>
fftw_real *work, int *use_work, int *ioutput_order)<br>
<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
.... So it must be a pointer issue revealed by the 64 bit, no? When I<br>
wasn't doing it "properly" the value of *ioutput_order wasn't set.<br>
<br>
</blockquote>
<br>
The value of the first element of local_data was used for the n_fields scalar.<br>
<br>
The work array was being laid down starting at the location of the use_work scalar.<br>
<br>
The FFTW_NORMAL_ORDER value was being interpreted as use_work scalar.<br>
<br>
Finally, ioutput_order scalar was some random value.<br>
<br>
So, a lot was going wrong there. It's just one of life's little, um, pleasures<br>
that it looked like it was working for your 32-bit test case. Don't worry, you'll<br>
likely do this again, as likely *every* one of us on this list has, too.<br>
<br>
BTW, Fortran passes by reference; that's why all args are pointers.<br>
<br>
<br>
</blockquote>
<br></span></div><div><span class="e" id="q_11b9b18d7dfa9724_3">
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Beowulf@beowulf.org</a><br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</span></div></blockquote></div><br>