Build fails with PHASTA code #392

jrwrigh · 2023-07-20T20:37:10Z

Trying to build core, I get:

In destructor ‘virtual ph::PhastaSharing::~PhastaSharing()’,
    inlined from ‘virtual ph::PhastaSharing::~PhastaSharing()’ at /home/jrwrigh/software/core/phasta/phLinks.cc:31:3,
    inlined from ‘virtual ph::PhastaSharing::~PhastaSharing()’ at /home/jrwrigh/software/core/phasta/phLinks.cc:29:12,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:134:1:
/home/jrwrigh/software/core/phasta/phLinks.cc:29:12: error: array subscript ‘ph::PhastaSharing[0]’ is partly outside array bounds of ‘unsigned char [16]’ [-Werror=array-bounds=]
   29 |     delete helperN;
      |            ^~~~~~~
In constructor ‘ph::PhastaSharing::PhastaSharing(apf::Mesh*)’,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:101:22:
/home/jrwrigh/software/core/phasta/phLinks.cc:24:39: note: object of size 16 allocated by ‘operator new’
   24 |     helperN = new apf::NormalSharing(m);
      |                                       ^
In destructor ‘virtual ph::PhastaSharing::~PhastaSharing()’,
    inlined from ‘virtual ph::PhastaSharing::~PhastaSharing()’ at /home/jrwrigh/software/core/phasta/phLinks.cc:31:3,
    inlined from ‘virtual ph::PhastaSharing::~PhastaSharing()’ at /home/jrwrigh/software/core/phasta/phLinks.cc:29:12,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:134:1:
/home/jrwrigh/software/core/phasta/phLinks.cc:30:12: error: array subscript ‘ph::PhastaSharing[0]’ is partly outside array bounds of ‘unsigned char [16]’ [-Werror=array-bounds=]
   30 |     delete helperM;
      |            ^~~~~~~
In constructor ‘ph::PhastaSharing::PhastaSharing(apf::Mesh*)’,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:101:22:
/home/jrwrigh/software/core/phasta/phLinks.cc:24:39: note: object of size 16 allocated by ‘operator new’
   24 |     helperN = new apf::NormalSharing(m);
      |                                       ^
In destructor ‘virtual ph::PhastaSharing::~PhastaSharing()’,
    inlined from ‘virtual ph::PhastaSharing::~PhastaSharing()’ at /home/jrwrigh/software/core/phasta/phLinks.cc:31:3,
    inlined from ‘virtual ph::PhastaSharing::~PhastaSharing()’ at /home/jrwrigh/software/core/phasta/phLinks.cc:29:12,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:134:1:
/home/jrwrigh/software/core/phasta/phLinks.cc:31:3: error: array subscript ‘ph::PhastaSharing::__as_base [0]’ is partly outside array bounds of ‘unsigned char [16]’ [-Werror=array-bounds=]
   31 |   }
      |   ^
In constructor ‘ph::PhastaSharing::PhastaSharing(apf::Mesh*)’,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:101:22:
/home/jrwrigh/software/core/phasta/phLinks.cc:24:39: note: object of size 16 allocated by ‘operator new’
   24 |     helperN = new apf::NormalSharing(m);
      |                                       ^
In member function ‘virtual bool ph::PhastaSharing::isOwned(apf::MeshEntity*)’,
    inlined from ‘virtual bool ph::PhastaSharing::isOwned(apf::MeshEntity*)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:43:30,
    inlined from ‘virtual bool ph::PhastaSharing::isOwned(apf::MeshEntity*)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:40:8,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:112:23:
/home/jrwrigh/software/core/phasta/phLinks.cc:42:9: error: array subscript ‘ph::PhastaSharing[0]’ is partly outside array bounds of ‘unsigned char [16]’ [-Werror=array-bounds=]
   42 |     if (isDG)
      |         ^~~~
In constructor ‘ph::PhastaSharing::PhastaSharing(apf::Mesh*)’,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:101:22:
/home/jrwrigh/software/core/phasta/phLinks.cc:24:39: note: object of size 16 allocated by ‘operator new’
   24 |     helperN = new apf::NormalSharing(m);
      |                                       ^
In member function ‘virtual bool ph::PhastaSharing::isOwned(apf::MeshEntity*)’,
    inlined from ‘virtual bool ph::PhastaSharing::isOwned(apf::MeshEntity*)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:43:30,
    inlined from ‘virtual bool ph::PhastaSharing::isOwned(apf::MeshEntity*)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:40:8,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:112:23:
/home/jrwrigh/software/core/phasta/phLinks.cc:44:12: error: array subscript ‘ph::PhastaSharing[0]’ is partly outside array bounds of ‘unsigned char [16]’ [-Werror=array-bounds=]
   44 |     return helperM->isOwned(e);
      |            ^~~~~~~
In constructor ‘ph::PhastaSharing::PhastaSharing(apf::Mesh*)’,
    inlined from ‘void ph::getLinks(apf::Mesh*, int, Links&, BCs&)’ at /home/jrwrigh/software/core/phasta/phLinks.cc:101:22:
/home/jrwrigh/software/core/phasta/phLinks.cc:24:39: note: object of size 16 allocated by ‘operator new’
   24 |     helperN = new apf::NormalSharing(m);
      |                                       ^
cc1plus: all warnings being treated as errors

This is with GCC 13.1.1, which might have something to do with it. I'm not super comfortable with C++, so I'm not quite sure what the issue is (other than something is being accessed outside array bounds). I'll take a look at it, but I'm not sure why I'd suddenly be running into issues.

The text was updated successfully, but these errors were encountered:

jrwrigh · 2023-07-20T23:09:09Z

Writing down what (little) I've figured out, focusing on the first error message, it's complaining specifically about the destruction of shr at the end of the getLinks() function call:

core/phasta/phLinks.cc

Line 101 in 97523f8

PhastaSharing shr(m);

Things I still don't understand:

Where is the unsigned char [16] part coming from?
- Well, I'm pretty sure it comes from /home/jrwrigh/software/core/phasta/phLinks.cc:24:39: note: object of size 16 allocated by ‘operator new’, but how "object of size 16" --> unsigned char [16] I don't know other than that's 16 bytes of data
From array subscript ‘ph::PhastaSharing[0]’, why is it trying to access the struct as an array?
- Like, object[0] is equivalent to *object (dereferenced pointer), but shr isn't a pointer, it's just a struct.

I'm guessing the answer to most of these questions lies somewhere in C++ lore I've yet to become familiar with...

cwsmith · 2023-07-21T02:00:35Z

Hi @jrwrigh. What repo/branch/commit is this?

jrwrigh · 2023-07-21T02:04:40Z

This is on master

cwsmith · 2023-07-21T02:13:59Z

Thanks. To confirm, you are using SCOREC/core master @ 97523f8 (the current HEAD)?

jrwrigh · 2023-07-21T04:03:37Z

Actually, in double checking, it's the branch in #391 so that I can actually build it with CGNS.

If I run with CGNS enabled on master, it fails (which is what #391 addresses). If I disable CGNS, it builds fine.

On the #391 branch, CGNS disabled compiles fine, but running with CGNS causes the above error messages.

jrwrigh · 2023-07-21T14:05:56Z

Ooooh, I think I know what's happening. It's the change in the C++ standard. Currently CGNS "requires" C++14, whereas the rest is C++11. I'm guessing that change in standard is what's causing the issues.

Specifically looking at this part of the CMakeLists code:

core/CMakeLists.txt

Lines 40 to 45 in 97523f8

    
           if(ENABLE_CGNS) #takes precedence over SCOREC_ENABLE_CXX11 
        
             message(STATUS "enabling cxx14") 
        
             bob_cxx14_flags() 
        
           elseif(SCOREC_ENABLE_CXX11) 
        
             bob_cxx11_flags() 
        
           endif()

Trying to compile with C++11 flags and CGNS enabled runs into different compiler errors, specifically with the CGNS source files (apfCGNS.cc and mdsCGNS.cc).

KennethEJansen · 2023-07-21T14:21:36Z

@cwsmith who is the maintainer of phLinks? I see @seegyoung as possibly the original author.
Has there been discussion of getting SCOREC/core to be C++14 compliant?
If not, is it more practical to find a way to get CGNS to tolerate C++11?

While I was not familiar at first with phLinks, it looks like it is what builds all the part boundary stuff so it is rather critical.

cwsmith · 2023-07-21T15:07:25Z

@jrwrigh @KennethEJansen I'm probably not going to have time to look at this in depth until later next week or the following week. I can provide brief inputs and answers until then. On that front, I'll first look into the C++ standards mentioned.

KennethEJansen · 2023-07-21T15:36:55Z

Understood @cwsmith . Actually, I was hoping that we could get this delegated to someone else given your scarce time OR determine that C++14 compliance for SCOREC/core was not in the near term achievable horizon in which case we should try to get the CGNS back compatible to C++11.

To be clear, we have no expectation of you picking up support of CGNS issues and won't be bugging you about that. Further, we might ask @a-jp for help (though I expect his support time is also scarce since this was a very valuable volunteer project that should not come with expectations of ongoing support). We as the consumers of this development will have to shoulder the load to get it compatible with phLinks and other C++11 blocked components or find a way to bypass them (since PETSc will likely be building its own version of the part boundary interfaces and does not really need us to do that).

jrwrigh · 2023-07-21T15:47:09Z

Looking into it, there's nothing about the CGNS library that's C++, so I'm guessing that it's simply that the source code of apfCGNS.cc and mdsCGNS.cc are just written in C++14 compliant way.

I'll spend a bit of time just taking whatever the compiler's suggestion to fix the non-C++11 compliant issues are and see if that resolves the issues.

KennethEJansen · 2023-07-21T16:14:53Z

Thanks. This seems the best approach and hopefully won't offend @a-jp too much. If it does, we can keep it on a branch that we use until SCOREC/core is ready to be C++14 compliant.

cwsmith · 2023-07-28T14:45:02Z

@jrwrigh Would you please share the cmake configuration command (i.e., cmake /path/to/pumi -DOPTION=foo ...) you are using?

jrwrigh · 2023-07-28T15:19:08Z

cmake ../core \
  -DCMAKE_C_COMPILER="mpicc" \
  -DCMAKE_CXX_COMPILER="mpicxx" \
  -DCMAKE_C_FLAGS="-Wno-error" \
  -DCMAKE_CXX_FLAGS="-Wno-error" \
  -DMESHES="../core/pumi-meshes" \
  -DCMAKE_EXPORT_COMPILE_COMMANDS=1 \
  -DIS_TESTING=ON \
  -DENABLE_ZOLTAN=ON \
  -DENABLE_CGNS=ON

daisy20170101 · 2024-01-10T22:02:01Z

HI I am using the version tag/2.2.7 and run into the same error as discussed here. I am using GCC/11.3.0. I am looking forward to updates:-)

cwsmith · 2024-03-05T21:21:23Z

PR #420 should fix the phLinks.cc build error. I didn't test with CGNS enabled.

cwsmith · 2024-03-06T14:58:31Z

#420 was just merged into develop. If the nightly tests pass I'll mark this as closed.

cwsmith added phasta cgns labels Jul 21, 2023

jrwrigh mentioned this issue Jul 21, 2023

Make CGNS code C++11 compliant #393

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build fails with PHASTA code #392

Build fails with PHASTA code #392

jrwrigh commented Jul 20, 2023

jrwrigh commented Jul 20, 2023

cwsmith commented Jul 21, 2023

jrwrigh commented Jul 21, 2023

cwsmith commented Jul 21, 2023

jrwrigh commented Jul 21, 2023

jrwrigh commented Jul 21, 2023 •

edited

KennethEJansen commented Jul 21, 2023

cwsmith commented Jul 21, 2023

KennethEJansen commented Jul 21, 2023

jrwrigh commented Jul 21, 2023

KennethEJansen commented Jul 21, 2023

cwsmith commented Jul 28, 2023

jrwrigh commented Jul 28, 2023

daisy20170101 commented Jan 10, 2024

cwsmith commented Mar 5, 2024 •

edited

cwsmith commented Mar 6, 2024

Build fails with PHASTA code #392

Build fails with PHASTA code #392

Comments

jrwrigh commented Jul 20, 2023

jrwrigh commented Jul 20, 2023

cwsmith commented Jul 21, 2023

jrwrigh commented Jul 21, 2023

cwsmith commented Jul 21, 2023

jrwrigh commented Jul 21, 2023

jrwrigh commented Jul 21, 2023 • edited

KennethEJansen commented Jul 21, 2023

cwsmith commented Jul 21, 2023

KennethEJansen commented Jul 21, 2023

jrwrigh commented Jul 21, 2023

KennethEJansen commented Jul 21, 2023

cwsmith commented Jul 28, 2023

jrwrigh commented Jul 28, 2023

daisy20170101 commented Jan 10, 2024

cwsmith commented Mar 5, 2024 • edited

cwsmith commented Mar 6, 2024

jrwrigh commented Jul 21, 2023 •

edited

cwsmith commented Mar 5, 2024 •

edited