search

sstsimulator / sst-elements

SST Architectural Simulation Components and Libraries
http://www.sst-simulator.org
Other
90 stars 119 forks source link

PRI_ADDR is not available on all compilers #2342

Open ukasz opened 6 months ago

ukasz commented 6 months ago

Usage of PRI_ADDR leads to compilation errors on "some" compilers. This macro should be set up manually if it is not defined by the compiler, otherwise it is not defined and compiler complains about missing type after % sign:

./os/vappruntimememory.h:447:110: error: expected ')' before 'PRI_ADDR'
  447 |             CALL_INFO, 16, VANADIS_OS_DBG_APP_INIT, "-> Pushing %" PRIu64 " bytes to the start of stack (0x%" PRI_ADDR ") via memory init event..\n",
      |

Memhierarchy defines it manually, but other elements are not so smart. Now there are so many usages of it that fixing it manually became annoying.

My OS: Ubuntu 22.04 GCC: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

feldergast commented 6 months ago

PRI_ADDR is defined in sst/core/interfaces/stdMem.h, which is included in the file giving you an error. This was a relatively recent addition to stdMem.h; is it possible you're using a slightly older version of SST core? However, I'm not sure why this would affect only some compilers so it may be something else.

ukasz commented 6 months ago

You are right it is a matter of using old rev core version, and switching to a newer one fixes the problem. However I still think that it would be better to define it by the elements if they want to use it. It breaks compatibility for no real reason as it is now.

feldergast commented 6 months ago

The #define for PRI_ADDR is associated with "typedef uint64_t Addr" in stdMem.h (they are defined on consecutive lines in the header file). If you are using the Addr typedef, then you also get the PRI code for it. PRI_ADDR shouldn't be used unless you are specifying an StandardMem::Addr as the type.

For the line you are seeing an error on, the type of start_stack_address should maybe be StandardMem::Addr in the function definition. So the issue is not necessarily in the use of PRI_ADDR in the print statement, but rather using StandardMem::Addr and PRI_ADDR consistently for the correct variables. This consistency issue should be addressed.

jwilso commented 2 weeks ago

@feldergast Does a new issue need to be created for StandardMem::Addr?