similar to: git revert support?

Yes, Danny's response directly addressed my concerns, thanks. Sorry I wasn't explicit about that. > On Oct 17, 2016, at 6:56 AM, Teresa Johnson <tejohnson at google.com> wrote: > > Hi Justin, > > Wanted to follow up to see if Danny's response or the other responses addressed your concerns. > > Rather than specific new features in gcc 4.8+, it is more an

According to the documentation at http://llvm.org/docs/GettingStarted.html#software, compiling LLVM with GCC requires at least version 4.7.0. However, there are apparently several problems building current LLVM/Clang with gcc 4.7.X. This proposal is to increase the minimum required GCC to 4.8. This is split off of the thread started here:

GCC LTO works ok for the test case with both bfd and gold linker. David On Tue, Oct 4, 2016 at 6:58 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote:

On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Small repro: > > __attribute__((weak)) int hello_world(); > > int test() { > if (hello_world) > return hello_world(); > return 0; > } > > $ clang -fuse-ld=gold -flto=thin -O2 -shared -fPIC -o libmore.so more.c > $ objdump -t libmore.so |grep hello >

In uint64_t RTDyldMemoryManager::getSymbolAddressInProcess(const std::string &Name) { there is reference to morestack: #if defined(__i386__) || defined(__x86_64__) // __morestack lives in libgcc, a static library. if (&__morestack && Name == "__morestack") return (uint64_t)&__morestack; #endif #endif // __linux__ && __GLIBC__ On Mon, Oct 3,

On Mon, Oct 3, 2016 at 3:53 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > What is the linker command line buidling liblldb.so? is libgcc.a passed in? > There is no difference in the linker command for liblldb.so or bin/lldb between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can see. The difference appears to be that the __morestack symbol is weak in

On Wed, Oct 12, 2016 at 9:14 PM, Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: > > According to the documentation at > > http://llvm.org/docs/GettingStarted.html#software, compiling LLVM with > GCC > > requires at least version 4.7.0. However, there are apparently several >

On Wed, Apr 29, 2015 at 11:19 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 10:55 AM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> On Wed, Apr 29, 2015 at 10:05 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> > >> > >> > On Wed, Apr 29, 2015 at 9:48 AM, Teresa Johnson

On Wed, Apr 29, 2015 at 10:05 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 9:48 AM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> Ok, thanks for the suggestion. I will rework the tests to do that. > > > In case you haven't found it already, %T in the lit syntax gives you a > uniquely named directory for

Ok, thanks for the suggestion. I will rework the tests to do that. Teresa On Wed, Apr 29, 2015 at 9:47 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 9:36 AM Justin Bogner <mail at justinbogner.com> wrote: >> >> Teresa Johnson <tejohnson at google.com> writes: >> > On Wed, Apr 29, 2015 at 6:27 AM, Renato Golin

Is -fsplit-stack option used anywhere? My wild guess is that with ld.bfd, the thinLTO link for the DSO does not bring in morestack.o from libgcc.a, but the hidden symbol is defined in lldb binary. David On Mon, Oct 3, 2016 at 1:54 PM, Teresa Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Aha - finally reproduced! The difference is using ld.bfd not ld.gold. With > that I

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at

On Thu, Mar 24, 2016 at 6:35 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-24, at 12:58, Teresa Johnson <tejohnson at google.com> wrote: > > > > > > > > On Thu, Mar 24, 2016 at 6:35 AM, Duncan Exon Smith <dexonsmith at apple.com> > wrote: > > > > > > On Mar 24, 2016, at 6:22 AM, Teresa

Sorry, operator error. I can reproduce now. Interestingly, this does not reproduce using gold, and they utilize the same underlying LTO API. Let me dig a little using save-temps and see where they diverge. Teresa On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > LLD revision is r331862. To add, I had initially tried it on r328903, > which also

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

+pcc who added the NativeObjectStream class Looks like a known gcc bug, fixed in 4.8: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 Not sure what we do in cases like this, if it is a gcc bug. On Mon, Oct 10, 2016 at 2:50 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Sat, Oct 08, 2016 at 11:02:37AM +0000, sylvain.bertrand at gmail.com > wrote: > > Hi, >

I still wonder if this would be an issue in _standard_ (not thin) LTO? This test seems to be OK on my (slightly modified) standard LTO flow, but I do wonder for a more general case. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Collingbourne

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

On Thu, Jul 13, 2017 at 8:37 AM, Christudasan D <xander.cd at gmail.com> wrote: > > Hi Teresa, > > Yes, we plan to have our code at CG directly. > We use our own linker. That's the pain. We might only get a partial > benefit of thinLTO which occurs at compile time. > There is no compile-time only benefit of ThinLTO. You'll need the linker to interface with the

No problem! I want to make sure you aren't blocked on trying ThinLTO. Thanks, Teresa On Mon, Aug 15, 2016 at 2:50 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Sorry I was working on another LLVM issue that more urgent for us, so > didn’t have much time to work on smaller test case. I’ll try the new API > and see if the issus is gone. Thanks! >