__FUNCTION__ is not portable.
__func__ is but it needs a C99 compliant compiler.
--Nysal
On Tue, Sep 8, 2009 at 9:06 PM, Lenny Verkhovsky wrote:
> fixed in r21952
> thanks.
>
> On Tue, Sep 8, 2009 at 5:08 PM, Arthur Huillet wrote:
>
>> Lenny Verkhovsky wrote:
>>
>>> Why not using __FUNCTION__
Hi All,
does C99 complient compiler is something unusual
or is there a policy among OMPI developers/users that prevent me f
rom using __func__ instead of hardcoded strings in the code ?
Thanks.
Lenny.
On Wed, Sep 9, 2009 at 1:48 PM, Nysal Jan wrote:
> __FUNCTION__ is not portable.
> __func__ is
__func__ is what you should use. We take care of having it defined in
_all_ cases. If the compiler doesn't support it we define it manually
(to __FUNCTION__ or to __FILE__ in the worst case), so it is always
available (even if it doesn't contain what one might expect such in
the case of __F
On Sep 9 2009, George Bosilca wrote:
On Sep 9, 2009, at 14:16 , Lenny Verkhovsky wrote:
does C99 complient compiler is something unusual
or is there a policy among OMPI developers/users that prevent me f
rom using __func__ instead of hardcoded strings in the code ?
__func__ is what you shoul
fixed in r21956
__FUNCTION__ was replaced with __func__
thanks.
Lenny.
On Wed, Sep 9, 2009 at 2:59 PM, N.M. Maclaren wrote:
> On Sep 9 2009, George Bosilca wrote:
>
>> On Sep 9, 2009, at 14:16 , Lenny Verkhovsky wrote:
>>
>> does C99 complient compiler is something unusual
>>> or is there a pol
I have seen that ROMIO goes wrong with fix 2014: A lot of ROMIO tests in
ompi/mca/io/romio/romio/test/ are failing
For example, with noncontig_coll2:
[inti15:28259] *** Process received signal ***
[inti15:28259] Signal: Segmentation fault (11)
[inti15:28259] Signal code: Address not mapped (1)
[in
Hi Ralph,
Looks good so far. The way I want to use is this to use /dev/tty as
the xml-file and send any other stdout or stderr to /dev/null. I could
use something like 'mpirun -xml-file /dev/tty >/dev/null 2>&1',
but the syntax is shell specific which causes a problem the ssh exec
se
On Tue, 2009-09-08 at 15:00 +0200, Thomas Ropars wrote:
> Hi,
>
> I'm working on r21949 of the trunk.
>
> When I run on a single node with 4 processes this simple program calling
> 2 times MPI_Comm_dup , the processes hang from time to time in the 2nd dup.
I can't reproduce this, how often does
Ashley Pittman wrote:
On Tue, 2009-09-08 at 15:00 +0200, Thomas Ropars wrote:
Hi,
I'm working on r21949 of the trunk.
When I run on a single node with 4 processes this simple program calling
2 times MPI_Comm_dup , the processes hang from time to time in the 2nd dup.
I can't reproduc
HmmmI never considered the possibility of output-filename being
used that way. Interesting idea!
I can fix that one, I think - let me see what I can do.
BTW: output-filename redirects stdout, stderr, and stddiag. So you
would get rid of everything that doesn't come through the xml path.
On Wed, 2009-09-09 at 17:44 +0200, Thomas Ropars wrote:
Thank you. I think you missed the top three lines of the output but
that doesn't matter.
> main() at ?:?
> PMPI_Comm_dup() at pcomm_dup.c:62
> ompi_comm_dup() at communicator/comm.c:661
> -
> [0,2] (2 proce
N.M. Maclaren wrote:
On Sep 9 2009, George Bosilca wrote:
On Sep 9, 2009, at 14:16 , Lenny Verkhovsky wrote:
does C99 complient compiler is something unusual
or is there a policy among OMPI developers/users that prevent me f
rom using __func__ instead of hardcoded strings in the code ?
__
Bottom line is: just hardcode the function name.
It isn't that hard, and it avoids confusion of sometimes getting
function names, and sometimes getting file names...which is why you'll
find everything (at least, that I have seen) hardcoded.
On Sep 9, 2009, at 12:45 PM, Eugene Loh wrote:
Well, I fixed it so that output-filename can take /dev/null as an
argument. Unfortunately, that doesn't help this issue as it merrily
redirects all stdout/err from the procs to /dev/null. :-/
Of course, that -is- what output-filename was supposed to do. It is a
way of sending the output fro
14 matches
Mail list logo