similar to: [RFC] Increase minimum supported GCC version for building LLVM to 4.8

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 >

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

+1 from me. But which version of 4.8.x? 4.8.0 was released in March 2013 while 4.8.5 is June 2015 (see https://gcc.gnu.org/releases.html <https://gcc.gnu.org/releases.html>) Thats an awfully long time between those dates, so i can’t imagine everyone being on 4.8.5, but shouldn’t we aim for the highest possible one if we’re bumping versions anyway? Looking at Ubuntu 14.04 LTS

On Wed, Oct 12, 2016 at 6:26 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Wed, Oct 12, 2016 at 10:28:36AM +0200, Antoine Pitrou via llvm-dev > wrote: > > On Tue, 11 Oct 2016 13:46:35 -0700 > > Michael Kuperstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > To the best of my understanding - because we want to be able to > bootstrap

+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, >

On Tue, 11 Oct 2016 13:46:35 -0700 Michael Kuperstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > To the best of my understanding - because we want to be able to bootstrap > clang with the system compiler that ships with various linux and BSD > distributions. > Windows has no equivalent concept. To elaborate on this: if you want to produce binaries compatible with old

Thank you very much for the references, we've missed this discussion from last week. Seeing that the RFC hasn’t got any new responses since Wed 12th, is now the time to declare that the community has accepted the proposal, and to update the docs? Or is there any formal deadline for objections to be raised? -----Original Message----- From: meinersbur at googlemail.com [mailto:meinersbur at

Hello, http://llvm.org/docs/GettingStarted.html#software lists "GCC >=4.7.0" among requirements for building LLVM. However, my attempt of building LLVM+Clang with gcc 4.7.3 has failed with a multitude of errors, such as: lib/LTO/Caching.cpp:74:7: error: looser throw specifier for 'virtual llvm::lto::localCache(std::string, llvm::lto::AddFileFn)::<lambda(unsigned int,

I am trying to revert a commit, and the instructions here don't work as the revert support was removed from the git-llvm script last week when the migration happened. The instructions on the website still reference it however: https://llvm.org/docs/GettingStarted.html#reverting-a-change-when-using-git I am going to do it manually, but a script would be helpful for automating the commit

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

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 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 >

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

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 3:50 PM, Teresa Johnson <tejohnson at google.com> wrote: > > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > > I use trunk, but it depends on how close to the bleeding edge you > > > are

On Tue, Oct 11, 2016 at 01:14:06AM -0700, Mehdi Amini wrote: > > > On Oct 11, 2016, at 1:11 AM, sylvain.bertrand at gmail.com wrote: > > > > Then? How to proceed? > > Submit a patch seems like the best way forward on the short term. Ok, the authors of the targetted code need to proceed to a re-design of their code regarding the use of c++ features. The git log tells

On Tue, Dec 20, 2016 at 5:05 PM, Teresa Johnson <tejohnson at google.com> wrote: > Hi Carsten, > > A few responses below, but first, can you get the link command for > lldb.so.3.9.1? Last time it was the lldb.so build that was using > ld.bfd with the gold plugin which was exposing this issue. Where would I find it in an otherwise already terminated process? > On Tue, Dec

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

LLD revision is r331862. To add, I had initially tried it on r328903, which also reproduced the issue. On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > Hi Teresa, > > Thanks for looking into this. I hadn't initially tried ToT, but it > reproduces in ToT as well when I tried. > > $ ./clang --version > > clang version 7.0.0