similar to: [LLVMdev] Missing 3.5.1 rc1 tag on libcxxabi

Hi, I'm pleased to say that my latest attempt at running test-release.sh finished with minor issues (see below) so I'm planning to provide an big-endian MIPS32r2 pre-built binary in the LLVM 3.5 as an experimental/beta release. I was originally hoping to provide little-endian binaries too but I think there's insufficient time remaining for me to get that ready in time for Phase 1

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

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

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

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

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 Jack, On Sat, Mar 2, 2013 at 8:15 AM, Jack Carter <Jack.Carter at imgtec.com> wrote: > Jia, > > I made what I believe to be the correct changes and rebuilt clang and llc. Are the results what you expected? I so I will prepare the patches for commitment. > > Jack > > clang ../mips_R_JiaLiu.c -o mips_R_JiaLiu.ll -emit-llvm -O3 -S -target mipsel-unknown-linux -std=gnu89

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,

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

> On 15.12.2014, at 15:45, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Sebastian Dreßler >> Sent: 15 December 2014 14:08 >> Cc: Ben Pope; Nikola Smiljanic; llvmdev >> Subject: Re: [LLVMdev] 3.5.1 Testing Phase

Yeah, I was just puzzled :D No worries. Cheers, Sebastian 2014-12-16 11:09 GMT+01:00 Daniel Sanders <Daniel.Sanders at imgtec.com>: > It looks like I missed that email completely, I started out replying to > Nikola and Hans which is why I was talking about Windows rather than OS X. > > > > I've just found your first email in my llvmdev folder and I think I see what

It looks like I missed that email completely, I started out replying to Nikola and Hans which is why I was talking about Windows rather than OS X. I've just found your first email in my llvmdev folder and I think I see what happened. My mail rules deliver llvmdev messages to a folder named llvmdev unless I'm directly addressed in which case it delivers to my inbox. It looks like you

2014-12-15 13:00 GMT+01:00 Daniel Sanders <Daniel.Sanders at imgtec.com>: >> LLVM: CodeGen/Mips/cconv/arguments-struct.ll > > Do you have the verbose lit output for this test? > I ran it again in verbose mode, but there were no additional outputs. Cheers, Sebastian

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

> > 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 under Ubuntu 13.10 amd64 I just compiled both my libcxx and my libcxxabi. I noticed this really weird behaviour, while trying to compile some C++11-compliant piece of code I get this error at runtime exception_ptr not yet implemented Aborted (core dumped) Now my experience tells me that this is something that can easily be related to the ABI, so I go to the official libcxxabi

Unfortunately I'm having lots of trouble with rc1 at this point: * libcxxabi can't build, because it requires unwind.h, which we do not yet have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for general consumption). * The test-release.sh script has no option to disable only libcxxabi, you can only disable libcxx, libcxxabi and libunwind together (maybe this

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

Hi, Sorry for the late report but I've only just found these issues. Llvm.org isn't working for me at the moment but I'll file tickets once it is. The issues are: 1. Almabench has some significant numerical differences and fails the reference check for some configs. I'm investigating this one at the moment but early indications are that it's a similar (but different)

Hi, I am observing the libcxx project can not be built without libcxxabi, but I thought libcxx should not depend upon other projects. Observed on x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200102/023ca21b/attachment.html>