search for: ruiu

...rt of override. > Does that mean we have a pure virtual function with implementation in Clang/LLVM? If so, I feel it's a little bit confusing. If not, we should remove such redundant pure virtual function declarations from derived classes, no? On Thu, Mar 6, 2014 at 3:00 PM, Rui Ueyama <ruiu at google.com> wrote: > >> On Thu, Mar 6, 2014 at 2:21 PM, Craig Topper <craig.topper at gmail.com>wrote: >> >>> It also doesn't do pure methods either. >> >> >> I think I don't quite understand what that means. Can you give me an >>...

...r 21, 2016 at 8:25 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > Also, if it can segfault for some pathetic input > > Surely that's a bug though, not seriously designed behaviour? > No. That is a design choice. > On Mon, 21 Mar 2016 at 19:24 Rui Ueyama <ruiu at google.com> wrote: > >> We do not enable exceptions and longjmp is not safe. Also, if it can >> segfault for some pathetic input, "it longjmps in most cases" doesn't help >> people who wants 100% guarantee like you. >> >> On Mon, Mar 21, 2016 at...

...rgs) { if (!Config->Relocatable) InputSections.push_back(createCommentSection()); - // Replace common symbols with regular symbols. - replaceCommonSymbols(); // Do size optimizations: garbage collection, merging of SHF_MERGE sections On Fri, Jun 21, 2019 at 8:39 PM Rui Ueyama <ruiu at google.com> wrote: > Let me investigate. > > On Fri, Jun 21, 2019 at 5:08 PM Mani, Suresh <Suresh.Mani at amd.com> wrote: > >> Thanks for the info Teresa, >> >> >> >> Regards >> >> M Suresh >> >> >> >> *From:...

> On Dec 13, 2016, at 11:51 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >> &gt...

On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:23 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.a...

On Thu, Mar 6, 2014 at 2:21 PM, Craig Topper <craig.topper at gmail.com> wrote: > It also doesn't do pure methods either. I think I don't quite understand what that means. Can you give me an example? > On Thursday, March 6, 2014, Rui Ueyama <ruiu at google.com> wrote: > >> After running the tool aginst LLD, I realized that clang-modernize do not >> add "override" to virtual destructors. I think it's not intended but just >> that that case is not covered by the tool. >> >> >> On Wed, Ma...

On 26 May 2015, at 20:13, Rui Ueyama <ruiu at google.com> wrote: > > I sent a patch to llvm-commits. You can see the code at http://reviews.llvm.org/D10036. Thanks! Why does the link not actually go where the text of it would imply, and instead bounce via some random (malicious?) third party? Do you have some malware infecting y...

On Mon, Oct 6, 2014 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 6, 2014, at 3:44 PM, Rui Ueyama <ruiu at google.com> wrote: > > Looks like most people in this thread support using LLVM style in LLD. I > also had an offline discussion and many people wanted to have one coding > style in all LLVM projects. So I'm convinced that we should do that. > > I'm going to create a...

I sent a patch for review. I'll wait for a while, probably submit that tomorrow. On Thu, Apr 9, 2015 at 2:14 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Thu, Apr 9, 2015 at 12:17 PM, Rui Ueyama <ruiu at google.com> wrote: > > I think I bought up this topic before, but I'd like to propose seriously > > removing the Native file format from LLD this time. > > > > IIUC, the Native file format was designed to be the fastest on-memory or > > on-disk file format fo...

The new linker is quickly becoming more than just an experiment. 64-bit COFF linker is mostly feature complete, and now we are having a direct translation of the COFF linker for ELF. Historically LLD has been suffered by over-designing and over-engineering. I don't want to repeat that again in the new codebase, so I'd like to be an owner of the new linkers (both for ELF and COFF), so that

It's not a big deal, but it always annoyed me a bit when I hit it, so I'll bring it up here. LLD represents an alignment X as log2(X) in some places and just X in other places. It's a bit confusing. Because I always think alignments in my mind in terms of 1, 2, 4, 8, ..., instead of 2^1, 2^2, 2^3, ..., I'd like to propose to always use real values. Any objections? --------------

Yes, it's very likely. It'd be very convenient if we could send a patch to buildbots for testing without actually submitting. On Thu, Jul 18, 2013 at 4:38 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Thu, Jul 18, 2013 at 4:29 PM, Rui Ueyama <ruiu at google.com> wrote: > > Hi LLVMdev, > > > > My recent commit r186623 caused buildbots for s390-linux and ppc64-linux > to > > fail. I rolled back that commit, and I'm trying to fix to re-submit. > > > > Is there any good way to debug the issue which d...

This looks really great to me Rui, and I’m also pleased to see the positive comments on the review thread. Thank you for driving this forward! -Chris > On Jul 4, 2019, at 9:50 PM, Rui Ueyama <ruiu at google.com> wrote: > > Hi all, > > I wrote a tool <https://reviews.llvm.org/D64123> to batch-rename variable names so that they are in camelCase, and I applied the tool to lld subdirectory. You can see my change at https://reviews.llvm.org/D64121 <https://reviews.llvm.o...

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Rui Ueyama" > <ruiu at google.com> > Sent: Tuesday, October 18, 2016 10:38:57 PM > Subject: Re: [llvm-dev] Embedding LLD version to executables > > On Oct 18, 2016, at 8:30 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > ----- Original Message ----- > > > > From: &quot...

...changes? > > > > *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Josh > Sharp via llvm-dev <llvm-dev at lists.llvm.org> > *Reply-To: *Josh Sharp <mm92126 at hotmail.com> > *Date: *Tuesday, March 19, 2019 at 3:15 PM > *To: *Rui Ueyama <ruiu at google.com> > *Cc: *via llvm-dev <llvm-dev at lists.llvm.org> > *Subject: *Re: [llvm-dev] Building lld > > > > I tried deleting my build directory and restarting from scratch > > > > $ cd llvm-project > > $ mkdir build && cd build > > $...

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

> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:23 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >> &gt...

Yes, that would be the long term plan. llvm-link ideally would share the same library. I'm not sure where it should live though. On Tue 14 Feb 2017 at 01:49, Rui Ueyama <ruiu at google.com> wrote: > I took a look at the code. Looks like you need a library to create import > library files in LLVM and use that from llvm-dlltool and LLD. Is that what > you are planning? > > On Mon, Feb 13, 2017 at 5:37 PM, Martell Malone <martellmalone at gmail.com&gt...

...eans it would just be the only plan then. I assume the first step would be to move the code from lld into this new library and lld can use that? I can then re add the extra functionality for weak externals? We can then have lib and dlltool use this then. On Tue 14 Feb 2017 at 01:58, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:56 PM, Martell Malone <martellmalone at gmail.com> > wrote: > > Yes, that would be the long term plan. > llvm-link ideally would share the same library. > I'm not sure where it should live though. > > > What...

...to have one coding style in all LLVM projects. So I'm convinced that we should do that. I'm going to create a patch to rename all variables if no one objects. On Mon, Oct 6, 2014 at 3:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Tue, Oct 7, 2014 at 8:54 AM, Rui Ueyama <ruiu at google.com> wrote: > >> would touch all the lines. Diff is not powerful enough to trace the >> history beyond variable renaming. svn blame would become useless. >> > > "useless" is much too strong a description. > > If svn blame points to the reforma...