similar to: [LLVMdev] Restoring "pubnames" section in DWARF

>We have customers that rely on the symbol information from the >"pubnames" section in the DWARF data. Generation of this information >was removed in this commit: > >commit dfa30e1ab243990eda4732a6dffb91e965e7a755 >Author: Eric Christopher <echristo at apple.com> >Date: Wed Nov 9 05:24:07 2011 +0000 > > Remove the pubnames section, no one consumes

On Fri, Jan 11, 2013 at 1:49 PM, Robinson, Paul <Paul.Robinson at am.sony.com>wrote: > >We have customers that rely on the symbol information from the > >"pubnames" section in the DWARF data. Generation of this information > >was removed in this commit: > > > >commit dfa30e1ab243990eda4732a6dffb91e965e7a755 > >Author: Eric Christopher

> In conclusion: > Why are people using Git disadvantaged? Short answer: because of git-svn and differences between what is a tag in git and svn. Long answer: git-svn never created proper git tags. Instead, it converted svn tags to branches (because technically branches and tags are same in svn). These branches were orphan and not usable for bunch of things (I believe Takumi can provide a

On Mon, Feb 9, 2015 at 9:47 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hans, > >>> I see a Git branch "release_36", but what has v3.6.0rc2 for a >>> commit-id, can you tags that? >>> No, there are no tags at all @ github. >> >> Anton, is it possible to translate the svn tags to git tags? > In the past we had problems

Hi, Rafael took some measurements to try to investigate the effect of the local symbols changes. I've been taking a look at the measurements he got and there were some interesting things we noticed. For starters, in the range of revisions tested (r263214 through r263471), we found that the commit for --build-id was the most noticeable, with slowdowns from 7% to 23% (note: these were

Hi, Compiling on PP64/FreeBSd, I get several of these: /usr/home/kparzysz/bld.lv/tools/llvm-mc/Release+Asserts/llvm-mc.o: In function `llvm::formatted_raw_ostream::~formatted_raw_ostream()': llvm-mc.cpp:(.text.startup.main+0xe4): undefined reference to `LLVMInitializeARM64TargetInfo' llvm-mc.cpp:(.text.startup.main+0x154): undefined reference to `LLVMInitializeARM64TargetMC'

Hi Anton, git-svn got confused at the branch point for the release_31: I see that the current release_31 branch has been created on r155051 as a copy of r155050 from trunk, and r155050 is actually removing an older release_31 branch: Revision 155050 Author: void Date: Wed Apr 18 16:38:33 2012 CDT (11 days, 20 hours ago) Log Message: Removing old release_31 branch for rebranching. This

To rebuild, it would be enough to remove .git/svn/refs/remotes/git-svn/.rev_map.* My usual way to resync; $ git fetch llvm.org (is remote name) $ git update-ref refs/remotes/git-svn llvm.org/master $ git svn fetch Partial-rebuilding .git/svn/refs/remotes/git-svn/.rev_map.91177308-0d34-0410-b5e6-96231b3b80d8 ... Currently at 124651 = 071d3af0de273b1079d79f7f979264f28d567373 r124653 =

After updating from trunk today, I am seeing this failure in hwasan: FAIL: HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp (19011 of 49508) ******************** TEST 'HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp' FAILED ******************** <snip> Command Output (stderr): -- + : 'RUN: at line 1' + /build/./bin/clang --driver-mode=g++ -fsanitize=hwaddress -mllvm

Hi ! Our buildbot found this regression while compiling the kernel with clang: A bisection points to 475ac5d302ba84ac13d34a9215c29c1a38ca5690 is the first bad commit commit 475ac5d302ba84ac13d34a9215c29c1a38ca5690 Author: Eric Christopher <echristo at gmail.com> Date: Thu May 15 01:10:50 2014 +0000 Unify command line handling of MCTargetOptions and remove extra options and

Hi, git messages for the LLVM source quote the equivalent SVN revisions with a line like this: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 165785 91177308-0d34-0410-b5e6-96231b3b80d8 But the URL doesn't work; instead we get the following error message: The requested URL /svn/llvm-project/llvm/trunk at 165785 was not found on this server. The tip of the trunk is visible

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > We'd need to look precisely at what's causing the code size bloat. The > midend commit pointed out by Steve shouldn't cause bloat in and of itself - > it should reduce code size. It removes a load of stores and branches. > Hi James, Sounds like your patch should have

LLVM builds with me on the release_33 branch, but fails on trunk. I bisected the problem to this commit: commit b49fb7bcd5001567d2da06f6a6e1c7ba79649e1b Author: Daniel Dunbar <daniel at zuster.org> Date: Wed Aug 14 23:15:39 2013 +0000 [llvm-build] Make Py3 compatible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 188424 91177308-0d34-0410-b5e6-96231b3b80d8

my compiler gave me a warning in MCObjectDisassembler.cpp. it found a self-comparation in loop condition. I think it's a typo. the suspicious code was introduced by this patch: >From f176482752fbea3139394e280adfb10270dd3aac Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha <ahmed.bougacha at gmail.com> Date: Wed, 21 Aug 2013 07:28:55 +0000 Subject: MC CFG: Support disassembly at

FYI, I have been maintaining my own release_31 manually on github.com/chapuni. 2012/5/1 Sebastian Pop <spop at codeaurora.org>: > Hi Anton, > > git-svn got confused at the branch point for the release_31: I see > that the current release_31 branch has been created on r155051 as a > copy of r155050 from trunk, and r155050 is actually removing an older > release_31 branch:

[ Original posting see [1] ] >From [1]: ... Added: llvm/tags/RELEASE_380/rc3/ (props changed) - copied from r261685, llvm/branches/release_38/ ... The LLVM Git repositories have no "rc3" tag in "release_38" branch (as an example llvm.git#release_38 see [2]). Who is responsible for that or maybe better... can you activate the responsible(s)? Helpful is to add

On Mon, Jan 30, 2017 at 9:34 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We need to disable most forms of IPO on naked functions. We already do this > in DeadArgElimination.cpp. We need to do it in more places. > +1. Carlo, can you please open a bug? -- Davide "There are no solved problems; there are only problems that are more or less solved"

On 2017-01-30 18:41, Davide Italiano wrote: > On Mon, Jan 30, 2017 at 9:34 AM, Reid Kleckner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We need to disable most forms of IPO on naked functions. We already do this >> in DeadArgElimination.cpp. We need to do it in more places. >> > > +1. Carlo, can you please open a bug? > Done

On 1/11/2013 4:04 PM, Eric Christopher wrote: > On Fri, Jan 11, 2013 at 1:49 PM, Robinson, Paul > <Paul.Robinson at am.sony.com <mailto:Paul.Robinson at am.sony.com>> wrote: > > I'd ask that it be made target-dependent, as I don't want it > (and apparently few do, which is why it was removed). > > > No worries there, it can be put under a flag