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 > > >
