Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by sumit_tuwien

  1. Your simulation was stuck because it was not proceeding with time ...
  2. valgrind can be used as a profiler here. the tool is callgrind. kcachegrind comes with kde is a nice viewer.
  3. Hello, Please use -fdelayed-template-parsing to bypass this bug for the time being. Regards, Sumit
  4. Hello Philipp, Would it be possible to bypass the bug by explicitly deleting the destructor [public : ~mclass() = delete;] if the the chosen c++ standard is at or above c++11 ? It started hurting now. Regards, Sumit
  5. Hello All, Using get_chil d_objects() I can traverse through hierarchy and can find any ports & instances But I cannot find how these ports are connected. All what I want to do is to create a database which I can use for visualization by post processing. Is there any way to do this ? Regards, Sumit
  6. Hello Eyck, This is an amazing pointer. I see I have created a lot of confusions by vaguely putting some code and not mentioning the intent. I will never construct this object. All I am interested is accessing const uint8_t duh { 5 } ; const uint16_t notEgal { Moeglich::Egal(duh) } ; Here is what is important for me: Sometimes, I need partial template specialization of functions which is not allowed which can be enabled if I put this function inside a template class. Your link, very clearly lays down the rule. My expectation from the compiler was wrong and my use-case cannot be understood in a special way by the compiler. Meanwhile, I also asked help from stackoverflow.com in here (I generally do not do that, because they are champions in downvoting questions). You can see how many confusing and different answers from people. Please note:: Since I always explicitly mention all 6 special member functions, it was fine. This was accidentally found when in one place I missed 4 of them and started wondering. Glad that I did that mistake, which enabled me to learn something and correct some mistakes in my understanding. Thanks for the great help. Regards, Sumit
  7. Hello David, Yes, but please note that I already applied final keyword at the end of the class and hence this class cannot be derived from. Regards, Sumit
  8. Hello All, I found out this issue while I was playing with some SystemC stuffs (During meta-programming). This is a C++ question which I separated out from the SystemC implementation. I could have gone to pure C++ forum but since I use this forum, I believe if I ask here people will be benefited more. I observed that if I explicitly delete only constructor and destructor of a class then the resultant implementation deletes copy constructor & move constructor, but the compiler still makes copy assignment and move assignment operators implicitly available! Which in turn makes assignment possible! My question is what is the rational of this? What is the use case where this can be used. Following is an example code for reference: # ifndef MOEGLICH_H_ # define MOEGLICH_H_ # include <cstdint> class Moeglich final { public : explicit Moeglich() = delete ; ~Moeglich() = delete ; /* // With explicit deletion Moeglich& operator=(const Moeglich& other) = delete ; Moeglich(const Moeglich& other) = delete ; Moeglich&& operator=(Moeglich&& other) = delete ; Moeglich(Moeglich&& other) = delete ; */ static constexpr uint16_t Egal(const uint8_t& var_) noexcept { return static_cast< uint16_t > ( var_ ) ; } }; # endif # include <cstdlib> # include <iostream> # include <type_traits> int main(int argc, char* argv[]) { std::cout << std::boolalpha << "Is constructible : " << std::is_constructible<Moeglich>::value << std::endl << "Is destructible : " << std::is_destructible<Moeglich>::value << std::endl << "Is copy constructible : " << std::is_copy_constructible<Moeglich>::value << std::endl << "Is move constructible : " << std::is_move_constructible<Moeglich>::value << std::endl << "Is copy assignable : " << std::is_copy_assignable<Moeglich>::value << std::endl << "Is move assignable : " << std::is_move_assignable<Moeglich>::value << std::endl << "Is assignable : " << std::is_assignable<Moeglich, Moeglich>::value << std::endl ; /* Following were what I wanted to bar anyway : const Moeglich mom {} ; Moeglich pop {} ; Moeglich foo {} ; foo = mom ; foo = std::move(pop) ; */ return EXIT_SUCCESS ; } Regards, Sumit
  9. Hello Eyck, If I can imagine an use case for this, it will be storing state of state machines or some enumerated values. If this is true, then storing numerical integral values will be sufficient and in the viewer, they can be mapped to respective ASCII values. If what I can imagine is correct use case, then this solution is better. Regards, Sumit
  10. Hello Anthony, I do not have any idea about CRAVE. SCV is alive and kicking. They even have released a recent version and cleaned up global namespace corruption issues. The version number is 2.0.1. We are using it under some limitation. Use scv and open the profiler and you can see how it behaves. it is extremely slow and heavy too (should not be a surprize). And hence we are using it in situations when we we need constrained randomization only. For every other case, I would suggest you to write a convenience class over c++11 random numbers - which is very clean way. Regards, Sumit Edit: Verification working group is working towards a new release, but till then please use scv-2.0.1 along with you own random helper classes for simple random numbers. Also, you might want to see this library http://randomlib.sourceforge.net/html/ meanwhile. I gave a thought about it, but I finally decided to use c++11 random numbers.
  11. Hello, I think vcd will not let you save a string (?). I am not sure if it will work, but can use string to integer conversion and save them in vcd file. And in your viewer (if there is a way, Cadence simvision has a way) you can convert these signal to ASCI. You can write to_string() which will do this job on your own. Regards, Sumit
  12. Hello All, I ran static analysis on latest SystemC library [For Fun]. clang-tidy report looks fine (I gave a very fast look). clang++ --analyze produced followed warnings which I want to point out: warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats In file included from ../src/sysc/datatypes/int/sc_int_base.cpp:66: ../src/sysc/datatypes/int/sc_int_base.h:574:22: warning: The result of the left shift is undefined because the left operand is negative m_val = ( m_val << m_ulen >> m_ulen ); ~~~~~~^~~~~~~~~ 1 warning generated. ../src/sysc/utils/sc_mempool.cpp:252:59: warning: Division by zero int which_allocator = cell_size_to_allocator[(sz - 1) / increment + 1]; ~~~~~~~~~^~~~~~~~~~~ 1 warning generated. warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats ../src/sysc/utils/sc_string.cpp:181:19: warning: Use of memory after it is freed return strlen(rep->str); ^~~~~~~~ ../src/sysc/utils/sc_string.cpp:242:9: warning: Use of memory after it is freed if (--(rep->ref_count) == 0) ^~~~~~~~~~~~~~~~~~ ../src/sysc/utils/sc_string.cpp:357:9: warning: Use of memory after it is freed if (rep->ref_count > 1) { ^~~~~~~~~~~~~~ 3 warnings generated. warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats In file included from ../src/sysc/kernel/sc_simcontext.cpp:32: In file included from ../src/sysc/kernel/sc_simcontext_int.h:37: ../src/sysc/kernel/sc_runnable_int.h:464:18: warning: Called C++ object pointer is null m_methods_pop = m_methods_push_head->next_runnable(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Even if these will not pose a problem for running simulations, I will get my sanitizer and other tools irked out. Following is the script if anybody want to try. set x = `find ../src -name "*.cpp"` foreach item ($x) /home/sumit/local/clang/bin/clang-tidy \ -checks='*' \ `echo ${item}` \ -extra-arg=-std=c++17 -- -I ../src end /home/sumit/local/clang/bin/clang++ --analyze -std=c++17 -I ../src \ `echo $x` Please let me know, if there is further questions. Regards, Sumit
  13. Hello Philip, Thanks for the pointer. I took special care during clang installation so that this does not happen. And looks like it happened. I will re install it again. Thanks a lot for the pointer - I was pretty sure this was not happening. Regards, Sumit
  14. Hello Philip, Adding some more info (All for c++17). For SystemC-2.3.2 lib compiled with gcc-6.2 and user code compiled with gcc-6.2 : Works lib compiled with clang-7 and user code compiled with clang-7 : Works lib compiled with gcc-6.2 and user code compiled with clang-7 : Fails during linking Question: Does it point some issue with my compilers ? Regards, Sumit
  15. Hello Philip, I confirm that the my clang-7 links with other libraries I built with gcc4.8.1. I just used my old systemc-2.3.1 (built with gcc-4.8.1) and it worked. Regards, Sumit
  16. Hello Philip, On :"can you please share some details on your remark that "it does not compile with -std=c++17"? For me, the SystemC 2.3.2 library and examples compile and run fine with GCC 6.3 and -std=c++17 (no 6.2 installation at hand here)." When I try to compile the library using /home/sumit/local/cmake/cmake-3.11.3-Linux-x86_64/bin/cmake ../ -DCMAKE_INSTALL_PREFIX:PATH=/home/sumit/systemc-2.3.2_cxx17 -DCMAKE_CXX_STANDARD=17 -DBUILD_SHARED_LIBS=OFF -DCMAKE_CXX_EXTENSIONS=OFF the build automatically chooses -std=gnu++1z instead of -std=c++17. On "Your linker errors look like you're missing the (matching) C++ runtime libraries in your linker call. Do you configure clang to use libc´╗┐++ instead of libstdc++? " Answer is no. On "Can you link any other C++ library built with GCC 6.2 to an application built with Clang 7? I would expect that this issue is not specific to SystemC and I would recommend to stick to a single compiler for all artifacts in your application, including SystemC." My understanding was, if we build a library in gcc the we cab use in clang. It has been some years we write portable code which we compile using gcc, clang and with EDA vendors of our choice. We generally compile our libraries (and they are quite a lot in number) using gcc so that we do not get any unsuspecting issues with EDA tools as they use gcc. using gcc/clang is a choice of the developer and EDA tools are used during ASIC developments mainly. We use clang tools especially clang static analysis capability here a lot. Till now with systemc-2.3.1 everything was fine. I am just trying to access how much it will make an impact - or can make in future. Regards, Sumit
  17. Hello Torsten, After updating the cmake. I compiled the library with new cmake. I made sure that the library compiled with the proper switch .............. cd /home/sumit/install/systemc-2.3.2/objdir/src && /home/sumit/local/gcc6.2/bin/c++ -DSC_BUILD -DSC_ENABLE_ASSERTIONS -DSC_ENABLE_EARLY_MAXTIME_CREATION -DSC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING -DSC_INCLUDE_FX -I/home/sumit/install/systemc-2.3.2/src -O3 -DNDEBUG -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -pthread -std=gnu++1z -o CMakeFiles/systemc.dir/sysc/communication/sc_event_queue.cpp.o -c /home/sumit/install/systemc-2.3.2/src/sysc/communication/sc_event_queue.cpp .............. Please note that it does not compile with -std=c++17. So I decide to compile my user code with the same -std=gnu++1z switch. But I get link error. Please note my systemc library has been statically linked. Errors are as follows (it is a long list actually): Linking CXX executable run.exe /home/sumit/systemc-2.3.2_cxx17/lib/libsystemc.a(sc_simcontext.cpp.o): In function `sc_core::sc_simcontext::init()': sc_simcontext.cpp:(.text+0x414): undefined reference to `operator delete(void*, unsigned long)' sc_simcontext.cpp:(.text+0x42c): undefined reference to `operator delete(void*, unsigned long)' sc_simcontext.cpp:(.text+0x444): undefined reference to `operator delete(void*, unsigned long)' sc_simcontext.cpp:(.text+0x45c): undefined reference to `operator delete(void*, unsigned long)' sc_simcontext.cpp:(.text+0x474): undefined reference to `operator delete(void*, unsigned long)' /home/sumit/systemc-2.3.2_cxx17/lib/libsystemc.a(sc_simcontext.cpp.o):sc_simcontext.cpp:(.text+0x490): more undefined references to `operator delete(void*, unsigned long)' follow /home/sumit/systemc-2.3.2_cxx17/lib/libsystemc.a(sc_simcontext.cpp.o): In function `sc_core::sc_simcontext::construct_hierarchical_name(sc_core::sc_object const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': sc_simcontext.cpp:(.text+0x10b8): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_aux(unsigned long, unsigned long, unsigned long, char)' All rest of the error are on this basic_string. What possibly would have gone wrong? Any idea ? Regards, Sumit P.S :: I am using gcc-6.2 for systemc compilation and clang-7 for user code compilation.
  18. Hello Torsten, Thanks a lot for the pointers. Regards, Sumit
  19. I am trying to use latest systemc library in combination with c++17. For earlier version of systemc, I had no issue to use -std=c++17 switch. I see in the INSTALL of current release, it is written in the section 5. * SC_CPLUSPLUS - Override automatically detected C++ standard support This setting allows downgrading the assumed version of the underlying C++ standard on the current platform. By default, the latest supported version is chosen. Supported values are * SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003) * SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011) * SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014) * SC_CPLUSPLUS=201703L (C++17, N4659: Working Draft, Standard for Programming Language C++) But when I tried to compile the library using -std=c++17 switch (I forced it manually by editing CMakeLists.txt) and then use it in the user code with the same switch, I got a linker error for an sc_api_version. Even if I compile the library without standard spec [By default it should be c++ 98] and use it in user code compiled with switch -std=c++17, I get the link error related to API. With the previous version, I was still able to use c++17 and now this is very different. I would like to know if I can compile systemc-2.3.2 with -std=c++17 switch and what is I am missing Regards, Sumit P.S: I am using clang at this point of time.
  20. Hello All, cmake ../ -DCMAKE_CXX_STANDARD=11 enables gcc specific switch -std=gnu++11 and "not" standard -std=c++11 And this is creating some side effects: When I try to use clang: cmake ../ -DCMAKE_CXX_STANDARD=11 -DCMAKE_INSTALL_PREFIX=/home/sumit/systemc-2.3.2/ -DBUILD_SOURCE_DOCUMENTATION=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ I see -std=c++11 option is not enabled during compilation: ............................................ [ 9%] Building CXX object src/CMakeFiles/systemc.dir/sysc/communication/sc_signal_ports.cpp.o cd /home/sumit/install/systemc-2.3.2/objdir/src && /usr/bin/clang++ -DSC_BUILD -DSC_ENABLE_ASSERTIONS -DSC_ENABLE_EARLY_MAXTIME_CREATION -DSC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING -DSC_INCLUDE_FX -I/home/sumit/install/systemc-2.3.2/src -O3 -DNDEBUG -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -pthread -o CMakeFiles/systemc.dir/sysc/communication/sc_signal_ports.cpp.o -c /home/sumit/install/systemc-2.3.2/src/sysc/communication/sc_signal_ports.cpp [ 9%] Building CXX object src/CMakeFiles/systemc.dir/sysc/communication/sc_signal_resolved.cpp.o cd /home/sumit/install/systemc-2.3.2/objdir/src && /usr/bin/clang++ -DSC_BUILD -DSC_ENABLE_ASSERTIONS -DSC_ENABLE_EARLY_MAXTIME_CREATION -DSC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING -DSC_INCLUDE_FX -I/home/sumit/install/systemc-2.3.2/src -O3 -DNDEBUG -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -pthread -o CMakeFiles/systemc.dir/sysc/communication/sc_signal_resolved.cpp.o -c /home/sumit/install/systemc-2.3.2/src/sysc/communication/sc_signal_resolved.cpp [ 9%] Building CXX object src/CMakeFiles/systemc.dir/sysc/communication/sc_signal_resolved_ports.cpp.o cd /home/sumit/install/systemc-2.3.2/objdir/src && /usr/bin/clang++ -DSC_BUILD -DSC_ENABLE_ASSERTIONS -DSC_ENABLE_EARLY_MAXTIME_CREATION -DSC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING -DSC_INCLUDE_FX -I/home/sumit/install/systemc-2.3.2/src -O3 -DNDEBUG -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -pthread -o CMakeFiles/systemc.dir/sysc/communication/sc_signal_resolved_ports.cpp.o -c /home/sumit/install/systemc-2.3.2/src/sysc/communication/sc_signal_resolved_ports.cpp .......... Regards, Sumit
  21. Hello Torsten, I confirm you that I am using library where I am not providing -DSCV_DISABLE_USING_NAMESPACES during the compilation of the SCV library itself. I am using DSCV_DISABLE_USING_NAMESPACES while compiling my user code. At this point of time, after some blind commenting/uncommening in my code, lastly I found that the source of the problem is a header file which is included from a very "infamous" C library. Earlier, we had some issues with scv include (scv-2.0.a), when this library defined a macro # define std::printf SOMETHING_I_DO_NOT_WANT_TO_DISCLOSE which I had to undef after the inclusion of this file. Again the issue is coming from here now! I will have to do further debug. Strange thing is that, last time it was easy to find the issue because of meaningful compiler message. But this time the compiler messages does not make any sense. Regards, Sumit
  22. Okay, giving up! Happy with dirty global namespace. Compiler messages makes no sense
  23. Hello Torsten, Greetings! Actually, initially I compiled the library without -DSCV_DISABLE_USING_NAMESPACES and started getting the error while compiling the suit with -DSCV_DISABLE_USING_NAMESPACES. I thought I misunderstood those lines in RELEASENOTES and hence I recompiled the library with -DSCV_DISABLE_USING_NAMESPACES and still getting the compilation error! The compilation error is not coming when I compile the suit without -DSCV_DISABLE_USING_NAMESPACES. I though I will be able to create a minimal reproduction easily and it did not show anything. This also indicates that there possibly something wrong the way I am using the library. Currently struggling with nonsensical messages from the compiler. I am trying to bring it down. Regards, Sumit
  • Create New...