This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vector lightweight debug mode


On 07/10/15 21:38 +0200, François Dumont wrote:
Hi

   I completed vector assertion mode. Here is the result of the new
test you will find in the attached patch.

With debug mode:
/home/fdt/dev/gcc/build_git/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:375:
Error: attempt to advance a dereferenceable (start-of-sequence) iterator 2
steps, which falls outside its valid range.

Objects involved in the operation:
   iterator @ 0x0x7fff1c346760 {
     type =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<int*,
std::__cxx1998::vector<int, std::allocator<int> > >,
std::__debug::vector<int, std::allocator<int> > > (mutable iterator);
     state = dereferenceable (start-of-sequence);
     references sequence with type 'std::__debug::vector<int,
std::allocator<int> >' @ 0x0x7fff1c3469a0
   }
XFAIL: 23_containers/vector/debug/insert8_neg.cc execution test


With assertion mode:
/home/fdt/dev/gcc/build_git/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1124:
Error: invalid insert position outside container [begin, end) range.

Objects involved in the operation:
   sequence "this" @ 0x0x7fff60b1f870 {
     type = std::vector<int, std::allocator<int> >;
   }
   iterator "__position" @ 0x0x7fff60b1f860 {
     type = __gnu_cxx::__normal_iterator<int const*, std::vector<int,
std::allocator<int> > >;
   }
XFAIL: 23_containers/vector/debug/insert8_neg.cc execution test

I still don't like the formatted output for the lightweight mode, it
adds a dependency on I/O support in libc, which is a problem for
embedded systems.

The idea was to just add really cheap checks and abort  :-(

Have you compared codegen with and without assertion mode? How much
more code is added to member functions like operator[] that must be
inlined for good performance?  Is it likely to affect inlining
decisions?

I suspect it will have a much bigger impact than if we just use
__builtin_abort() as I made it do originally.

If these checks become more complex then people are not going to
enable them by default, and we probably won't want to make them
enabled by _FORTIFY_SOURCE.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]