similar to: [LLVMdev] GNU LLD build error? Seems that Clang likes LLD just fine.

We should make LLD to be able to build with GCC even if GCC is a bit buggy. So you wrote that it's no longer build because of the recent change of makeArrayRef removal? I think it's my change (r196475). Can you confirm that you can build if you revert that change? If it has caused the build with GCC to break, we should roll it back. On Sun, Dec 8, 2013 at 3:45 PM, Mikael Lyngvig

On Sat, Dec 7, 2013 at 10:00 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > On 2013 Dec 7, at 04:23, Mikael Lyngvig <mikael at lyngvig.org> wrote: > >> I am using the -std=c++11 flag to GCC. > > I didn’t even look at your errors, but my understanding is that -std=gnu++11 is more used (and much better tested) than -std=c++11. Any chance that fixes it

I tried this command to undo the change (which should revert to the change just before the one you mentioned): svn update -rr196474 Then I built from scratch. This time it built, so I suppose it is revision 196475 that is the problem. -- Mikael 2013/12/9 Rui Ueyama <ruiu at google.com> > We should make LLD to be able to build with GCC even if GCC is a bit > buggy. So you

On 2013 Dec 7, at 04:23, Mikael Lyngvig <mikael at lyngvig.org> wrote: > I am using the -std=c++11 flag to GCC. I didn’t even look at your errors, but my understanding is that -std=gnu++11 is more used (and much better tested) than -std=c++11. Any chance that fixes it for you?

Yup, I can confirm that. Then the question is if LLD shouldn't compile with GNU, even if GNU is buggy. Personally, I think it is worth a lot to be able to build with GCC, but I don't know how the LLD developers feel about that. -- Mikael 2013/12/7 Simon Atanasyan <simon at atanasyan.com> > On Sat, Dec 7, 2013 at 10:00 PM, Duncan P. N. Exon Smith > <dexonsmith at

On Tue, Jan 20, 2015 at 6:06 PM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jan 20, 2015 at 5:42 PM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >>> On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> >>>

On Sun, Oct 6, 2013 at 8:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, > but unwind semantics are not enabled. Specify /EHsc > (C:\lld-x86_64_win7\lld-x86_**64-win7\llvm.src\tools\lld\** >

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (C:\lld-x86_64_win7\lld-x86_64-win7\llvm.src\tools\lld\lib\ReaderWriter\ELF\Hexagon\HexagonLinkingContext.cpp) [C:\lld-x86_64_win7\lld-x86_64-win7\llvm.obj\tools\lld\lib\ReaderWriter\ELF\Hexagon\lldHexagonELFTarget.vcxproj]

Hi, I'm analysing the LLD code structure (aka architecture) and am trying to mold it into a component model. Currently I see 4 components: - Driver - ReaderWriter - Passes - Core I wonder if this is the order that they're supposed to be in, since there are also code dependencies upwards from: Core -> ReaderWriter Passes -> ReaderWriter ReaderWriter -> Driver For a

On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I wanted to go through and map out the layering of LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > >

I've run a new scan of LLD's architecture and it appears to be getting cleaner! There are still some upward dependencies however: - core depends on Reader and Writer - passes depend on Reader and Writer - ReaderWriter/PECOFF/ReaderCOFF.cpp depends on Driver.h The updated architecture can be seen here: http://www.c2lang.org/docs/lld_architecture_20140710.png On Tue, Jun 3, 2014 at 3:07

I wanted to go through and map out the layering of LLD's libraries today and found that it's essentially impossible. I think some serious cleanup is needed here. Let's start with the purely link-level dependencies encoded in the CMake build: Curently the Core library depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core

The inverted dependency of Core to ReaderWriter via Simple.h was already present. My idea was to fix the problem before it gets bigger. My proposal would be to move Simple.h and Alias.h to Core. Similar to UndefinedAtom.h etc. It would be even nicer to make the naming consistent as well, since there already is UndefinedAtom.h SharedLibaryAtom.h etc Maybe: SimpleAtom.h AliasAtom.h Moving the file

Hi, I've been following the changes in LLD's software architecture. Recently a new file was added: Alias.h In this file, the curret Atom set is extended with an AliasAtom. While the change seems innocent enough, it has some nasty potential. Simple.h and Alias.h are placed in the ReaderWriter component. This is the 2nd component in the layering: Driver ReaderWriter Passes Core The problem

That reminds me: Do the web documents reside in a repository somewhere or should I just grab them using wget? 2012/6/14 Michael Spencer <bigcheesegs at gmail.com> > On Wed, Jun 13, 2012 at 4:02 PM, Mikael Lyngvig <mikael at lyngvig.org> > wrote: > > If nobody else is doing it, I can translate the FAQ into Sphinx as I'd > like > > to begin gradually extending

On Mon, Jun 2, 2014 at 12:49 AM, Rui Ueyama <ruiu at google.com> wrote: > I agree to move these files to Core. Any objections? None here. - Michael Spencer > > On Mon, Jun 2, 2014 at 12:44 AM, Bas van den Berg > <b.van.den.berg.nl at gmail.com> wrote: >> >> The inverted dependency of Core to ReaderWriter via Simple.h was already >> present. >> My

Hi, I've found a crash in lld when using linker script with wildcard matching. An example linker script: INPUT(os/main.o os/foo.o os/startup.o) OUTPUT(k.bin) SECTIONS { . = 0x0 .text : { *startup.o (.text) } .text.2 : { *(.tex*) } } I've wrote up a patch to fix this crash. Index: tools/lld/lib/ReaderWriter/LinkerScript.cpp <+>UTF-8

On Wed, Nov 20, 2013 at 6:11 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi Renato, > > My XU is on build 141 and there hasn't been a single problem yet. No > reboots, no crashes, and as far as I have observed no core dropouts (after > I did the cpu-freq trick you sent me). Perhaps I have a stable board or > perhaps it is because of its revision (rev. 0.3)?

On Sat, Nov 16, 2013 at 9:15 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > http://llvm.lyngvig.org/Articles/How-to-Setup-an-Arch-Linux-Buildbot-for-LLVM > Notice: You only need Ninja for the test build; none of the official LLVM builders use Ninja as far as I know. My buildbots use ninja. > Please notice that you must specify the absolute path to ninja, otherwise CMake

On Wed, Jun 13, 2012 at 4:47 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > That reminds me: Do the web documents reside in a repository somewhere or > should I just grab them using wget? The website is at http://llvm.org/viewvc/llvm-project/www/trunk/ . The llvm docs are in llvm/docs. Which actually makes me wonder if the LLVM-project FAQ (in reference to Chandler's post in