similar to: [LLVMdev] Pre-built big-endian MIPS32r2 binaries

> > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > If it's something that's overridden later because it can't be

Hi, I'm pleased to announce that the MIPS integrated assembler is now good enough to recurse the compiler for MIPS32R2, build a bootable Linux kernel for MIPS32R2, and pass LNT testing for a variety of 32-bit MIPS targets. I've therefore enabled it by default for all 32-bit MIPS targets in both LLVM and Clang. We're not aiming for perfect GAS compatibility but you should find that

> > Note that the same problems exist and that they are unrelated to the existence > > of TargetMachine or not since TargetMachine gets the relevant information from > > the Triple it holds. This information is incorrect, even as a starting point. > > I believe we're going to disagree here as the TargetMachine does not get all of its > information from the Triple -

Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu' -mips64r2 -mabi=64' should produce an ELF64 and 'clang -target mips64-linux-gnu -mips32r2 -mabi=32' should produce an ELF32. In terms of code,

> -----Original Message----- > From: Tom Stellard [mailto:tom at stellard.net] > Sent: 24 November 2014 17:15 > To: Daniel Sanders > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > Subject: Re: Proposed patches for Clang 3.5.1 > > On Mon, Nov 24, 2014 at 04:33:28PM +0000, Daniel Sanders wrote: > > Hi, > > > > I'd like to propose the

Rewrote the ABI example in terms of clang -cc1as which is a supported tool. Note that the same problems exist and that they are unrelated to the existence of TargetMachine or not since TargetMachine gets the relevant information from the Triple it holds. This information is incorrect, even as a starting point. Please do read the other examples in my previous email. It contains a number of

> OK, I'm going to just reply to the last because I think it's the most important part of all this and would like to try to have us side tracked again. If you'd like I can reply to it, but let's take the last part first :) > > > > Could you please provide some examples of things that are impossible right now > > > with command lines, how those interact with

Hi, I'd like to propose the following patches for inclusion in Clang 3.5.1. Proposed clang patches: * r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit -target * r214025 - [Driver][Mips] Check output of -dynamic-linker arguments by the Clang driver * r214662 - [Mips] Add the `mips64-linux-gnu` target to the test case to check `in128` type handling. *

Hi Tom, I saw the tags go in and tried to start the builds but it seems that you forgot one: $ LANG=C CFLAGS=-mips32r2 CXXFLAGS=-mips32r2 ./test-release.sh -triple mips-linux-gnu -build-triple mips-linux-gnu -no-64bit -j4 -release 3.5.1 -rc 1 # Validating llvm SVN URL # Validating cfe SVN URL # Validating dragonegg SVN URL # Validating compiler-rt SVN URL # Validating libcxx SVN URL # Validating

Eric Christopher echristo at gmail.com<mailto:echristo at gmail.com> writes: > The lack of a TargetMachine at the MC level was something I brought up a long time ago in this thread > with my proposed solutions. This is what needs to be fixed, especially given that targets can switch ISA, > ABI, floating point, etc within a single assemble action. I’ve been watching this thread in

Hi Eric, as I was working on the same issues that are covered in your patch I also made a change in clang driver to pass this option to the assembler. Could you please review it and tell me your opinion? http://reviews.llvm.org/D6091 Thanks Vladimir ________________________________ From: Daniel Sanders Sent: Wednesday, January 28, 2015 8:59 PM To: Eric Christopher; Vladimir Medic; llvmdev at

> > > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > > If it's something that's overridden later

> Ben reports that he didn't get a tarball even after the rpath fix and > had to disable -o pipefail to get one. Still not sure what caused > this. 'make check' failures can cause this. I had to revert r241599 to get a package. > Appendix: compiler-rt test failures > =================================== > Just to add Mips to this: On big-endian Mips32r2:

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because

Daniel, Note the openmp library only has cmake build machinery preventing autoconf-based builds. Jack On Tue, Jun 23, 2015 at 10:18 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > I'll do Mips as usual. Are we going to do an autoconf-based build for LLVM 3.7? If so, I might try Mips64 packages too. > >> -----Original

Hi Lang, Thanks for your help at the Hackers Lab. Fixing the problems we identified in RuntimeDyldMachOARM.h improves the MachO_ARM_PIC_relocations.s test quite a lot but there's one failed check that's proving a bit stubborn: Expression '*{4}(stub_addr(foo.o, __text, baz)) = 0xe51ff004' is false: 0x4f01fe5 != 0xe51ff004 I'm struggling to find the cause of

> > - Using CMake for the release binaries. I think I promised we'd do > > this for 3.7. I haven't actually started looking at this yet, but I'm > > still optimistic. > > I'm absolutely in agreement with this. Most of us already use CMake > for development, a lot of the buildbots are based on it and I think we > all agree that autoconf is deprecated.

Hi, I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select

On Wed, Jul 22, 2015 at 7:03 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> Ben reports that he didn't get a tarball even after the rpath fix and >> had to disable -o pipefail to get one. Still not sure what caused >> this. > > 'make check' failures can cause this. I had to revert r241599 to get a package. Oh, I'm silly. Some part of my

> Why isn't the ABI reflected in the triple? Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu toolchains both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely