similar to: [LLVMdev] RFC: Adding attribute(nonnull) to things in libc++

On Wed, Jun 3, 2015 at 12:21 AM, Nick Lewycky <nlewycky at google.com> wrote: > On 1 June 2015 at 07:20, Marshall Clow <mclow.lists at gmail.com> wrote: > >> This weekend, I got an email from Nuno Lopes informing me that UBSAN now >> paid attention to attribute(nonnull), and he was having some problems with >> it going off when using libc++. >> > >

On Mon, Jun 01, 2015 at 09:57:17AM -0700, Reid Kleckner wrote: > Why should memset / memcpy be attribute nonnull? Is there standardese that > supports that? The generic entry text of the standard section. IMO this is a standard bug and someone should *please* get it fixed. It is ridiculous that zero sized operations are considered UB. Joerg

On Mon, Jun 01, 2015 at 10:52:20AM -0700, Marshall Clow wrote: > P.S. recent gcc (at least 4.8.x and later) make optimizations based on > this UB (i.e, if you pass a pointer to memcpy, then it can't be NULL). BTW, this seems to be more an issue with glibc adding the tagging and not behavior of GCC itself. Joerg

> On Aug 10, 2018, at 13:28, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 26, 2018 at 9:20 PM, Eric Fiselier via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > Hi All, > > I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has.

Hi, I've just tagged LLVM 9.0.1-rc3. Testers can begin testing and uploading binaries. This will be the last release candidate unless there is a major problem. I'm planning to tag the final release on Dec 19. -Tom

Hi, I've tagged the LLVM 9.0.1-rc1 release. Testers can begin testing and upload binaries. I've also updated the test-release.sh script to pull from GitHub instead of SVN, if you run into any issues with the new script, let me know. -Tom

Hi, I've just tagged the 9.0.1-final release. Testers can begin uploading binaries. -Tom

Hi, I've tagged LLVM 9.0.1-rc2. Testers can begin testing and uploading binaries. If all goes well, this will be the last -rc. -Tom

Hi, Trying to compile llvm with the following configuration on Linux x86-64: cmake -G Ninja -DBUILD_SHARED_LIBS=ON \ -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold" \ -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold"\ -DCMAKE_BUILD_TYPE=RelWithDebInfo ' \ -DCMAKE_C_FLAGS="-O2 -g" \

Hello everyone, 9.0.0-rc5 was just tagged from the release_90 branch at r371837. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc5. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc5 Binaries will be added as they become available. There is only a single change from rc4 to rc5. Once more, the hope is that this will be the last release candidate and that we can

Hello again, 9.0.0-rc4 was just tagged from the release_90 branch at r371490. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc4. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc4 Binaries will be added as they become available. There are not a lot of changes from rc3 to rc4, and there are again no open release blockers, so I'm hoping this will be the last

Hi, I see the following variables in the CMakeCache.txt: SANITIZER_CXX_ABI:STRING=default //STRINGS property for variable: SANITIZER_CXX_ABI SANITIZER_CXX_ABI-STRINGS:INTERNAL=none;default;libcxxabi;libstdc++ Regards, ismail On Tue, Aug 1, 2017 at 7:32 PM, Vedant Kumar <vsk at apple.com> wrote: > >> On Aug 1, 2017, at 7:07 AM, İsmail Dönmez via llvm-dev <llvm-dev at

Hi All, I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has. First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem. Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and

Hello everyone, 9.0.0-rc3 was tagged today from the release_90 branch at r370450. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc3. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc3 Binaries will be added as they become available. There are currently no open release blockers, which means if nothing new comes up, the final release could ship soon and this is

Hello everyone, 9.0.0-rc6 was just tagged from the release_90 branch at r372100. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc6. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc6 This is the same as rc5 plus one very minor change (r371969) that still seemed good to pick up. I'm not allocating extra time for testing this one, expecting to tag

I haven't been able to figure out from this thread why this attribute is necessary at all. Anonymous or unnamed namespaces were added to C++ for this very purpose, but the ISO C++ Standard does not discuss "linkage" per-se because it is outside the scope of the language specification. But it does describes it in terms of having a hidden name which is "unique" to the

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris > Lattner via llvm-dev > Sent: Saturday, October 31, 2015 2:58 PM > To: sstewartgallus00 at mylangara.bc.ca > Cc: LLVM Developers > Subject: Re: [llvm-dev] [cfe-dev] [RFC] __attribute__((internal_linkage)) > > Hi Stewart, > > I saw this get brought up at

With respect only to '__attribute__((internal_linkage))', not 'nodebug' and other parts of this topic; does hiding "some" members and not others not introduce a violation of the ODR because some members of the class as it appears in one translation unit are not the same actual definitions as the apparently "same" members of the class in another translation unit?

Hi Evgenii, I was wondering what the status is of your work to attach "internal_linkage" to methods of standard library classes in libc++. The following piece of code doesn't link because a symbol (string::empty) is undefined and it sounds like your work might fix the linkage error I'm seeing. $ cat test1.cpp #include <string> #include <functional> int main() {

# Everything is done on Mac OS X 10.8.4, with llvm/clang/libc++/libc++abi built from source this morning # totclang is an alias for the built clang. $ export LLVM=/Sources/LLVM $ export LIBCXX=$LLVM/libcxx $ export LIBCXXABI=$LLVM/libcxxabi $ totclang -std=c++11 -stdlib=libc++ -I $LIBCXX/include -fsanitize=undefined ubsan.cpp -L $LIBCXX/lib -L $LIBCXXABI/lib -lc++abi $