On Wed, Jun 5, 2013 at 11:40 PM, Andrew Pinski <pins...@gmail.com> wrote: > On Wed, Jun 5, 2013 at 12:23 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Wed, Jun 05, 2013 at 11:44:07AM -0700, Andrew Pinski wrote: >>> On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek <pola...@redhat.com> wrote: >>> > Comments, please? >>> I think it might be better to do handle this while gimplification >>> happens rather than while parsing. The main reason is that constexpr >>> might fail due to the added function calls. >> >> Gimplification is too late, the FEs perform various operation shortenings >> etc. in many cases, and what exactly is undefined behavior is apparently >> heavily dependent on the particular language (C has different rules from >> C++). Yes, constexpr is something to consider in this light, but not >> something that can't be handled (recognizing ubsan builtins and just >> handling them specially). >> >>> Also please don't shorten file names like ubsan, we already have file >>> names which don't fit in the older POSIX tar format and needs extended >>> length support. >> >> We already have asan.c and tsan.c, and that is how it is commonly called. > > Can we just move them to array-sanitizer and thread-sanitizer? I
s/array-sanitizer/address-sanitizer/ If we are going to import the ubsan run-time from LLVM's projects/compiler-rt/lib/ubsan, we may also need to update the contents of libsanitizer/sanitizer_common and keep them in sync afterwards. (ubsan shares few bits of code with asan/tsan/msan) The simplest way to do that is to extend libsanitizer/merge.sh --kcc > think those are better names than asan and tsan. Shorten names are > not useful when a new person is learning the code. > > Thanks, > Andrew > >> >> Jakub
