Hey Satish: Thanks for your help. I did not mention this, but it’s both for intel compilers (modules intel15 and intel17). I have not checked in detail. I think I’ll opt for your second suggestion. I do not want to introduce compiler specific defines excessively throughout my code.
Considering the error handling: Sorry for not being precise. I am referring to any of the examples in the documentation (I did not check all, obviously). Here are two: http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/examples/tutorials/ex1.c.html <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/examples/tutorials/ex1.c.html> or a more sophisticated one: http://www.mcs.anl.gov/petsc/petsc-current/src/tao/bound/examples/tutorials/plate2.c.html <http://www.mcs.anl.gov/petsc/petsc-current/src/tao/bound/examples/tutorials/plate2.c.html> None of these examples for user routines contain any CHKERRQ calls anymore. A [Metainfo: A student asked me why I use these; I explained and referred him to the documentation; we then discovered that the examples do not use the error handling any longer] > On Dec 19, 2016, at 4:09 PM, Satish Balay <[email protected]> wrote: > > PETSc code doesn't use classes - so we don't see this isssue. > > One way to fix this is: > > #undef #undef __FUNCT__ > > #if (__INTEL_COMPILER) > #define __FUNCT__ “ClassName::FunctionName” > #else > #define __FUNCT__ “FunctionName” > #endif > > Alternative is to not do this check For compiles that define __func__ > [like intel, gcc] __FUNCT__ is not used anyway. So perhaps the following > will work? [without having to modify petsc include files] > > #undef PetscCheck__FUNCT__ > #define PetscCheck__FUNCT__() > > Wrt CHKERRQ() - which code are you refering to? > > Satish > > On Mon, 19 Dec 2016, Andreas Mang wrote: > >> Hey guys: >> >> I have some problems with the error handling. On my local machine (where I >> debug) I get a million warning messages if I do >> >> #undef __FUNCT__ >> #define __FUNCT__ “ClassName::FunctionName” >> >> (i.e., file.cpp:XXX: __FUNCT__=“ClassName::FunctionName" does not agree with >> __func__=“FunctionName”) >> >> If I run the same code using intel15 compilers it’s the opposite (which I >> discovered just now). That is, I get an error for >> >> #undef __FUNCT__ >> #define __FUNCT__ “FunctionName” >> >> (i.e., file.cpp:XXX: __FUNCT__=“FunctionName" does not agree with >> __func__=“ClassName::FunctionName”) >> >> I do like the error handling by PETSc. I think it’s quite helpful. >> Obviously, I can write my own stack trace but why bother if it’s already >> there. I did check your online documentation and I could no longer find >> these definitions in your code. So, should I just remove all of these >> definitions? Is there a quick fix? Is this depreciated? >> >> >> Second of all, I saw you do no longer use error handling in your examples at >> all, i.e., >> >> ierr = FunctionCall(); CHKERRQ(ierr); >> >> and friends have vanished. Why is that? Is it just to keep the examples >> simple or are you moving away from using these Macros for error handling. >> >> I hope I did not miss any changes in this regard in one of your >> announcements. I could not find anything in the documentation. >> >> Thanks >> Andreas >> >> >>
