similar to: [RFC] [tools] Changing Behavior of LLVM binutils When No File Is Specified

> Does anyone actually use the default to a.out behavior? This is a good point. What bugs me is continuity across the tools, I agree with you that it isn't particularly useful to default to a.out. But we are kind of stuck with the weird way that GNU's binutils do things. I am not in favor of llvm-objdump defaulting to a.out, but llvm-readelf giving this warning message. My guess is that

Sounds good, I'll work on removing these in favor of defaulting to stdin then? > I think it would be much friendlier to just print "file or pipe expected" and then print the help. Do you have thoughts on this? I'm not sure there is a clean way to do this, the cleanest would be through getFileOrSTDIN(), but I'm not sure all of its users want this behavior. I don't

Like James, Michael suggested, I would prefer the default behavior be consistent across tools (either always read from stdin or no default at all /give error messages) From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, June 26, 2019 2:31 AM To: Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Cc: Fāng-ruì Sòng <maskray at google.com>; LLVMDev

I have been working towards this on D63859. My current route was to add an optional callback to MemoryBuffer::getFileOrSTDIN which will be executed if stdin has not been redirected. James and I were talking over there and are maybe deciding that this might not be the best solution. The alternative in my mind is that the tools which want this behavior could do so by explicitly testing if

Hi, I want to write unit tests for a project I am working on. I need to create object files, preferably I want to have yaml files in the source tree and have cmake generate object files using yaml2obj. Does anyone know what I would put in the CMakeLists.txt to get this behavior? For a concrete example if I didn’t explain clearly: In llvm/unittests/Object I would maybe have an Inputs directory,

Thanks James! Thanks for the help. I certainly see your point. > In either case, if you wanted to change the test input, you'd need to rerun CMake again This is unfortunate, I would have hoped I could have CMake create $(wildcard *.yaml) type of output in the make files. But it sounds like this doesn't exist on make alternatives, so this wont work. There is actually a function to get

Hi Tim and Alex Thanks for your replies. So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this? Thanks, Joan > On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev > <llvm-dev at

Thanks for the reply. Typing in my username and clicking "Forgot password?" got me a link I could use to log in. It'd still be good if federated login worked again. Is there an upstream issue for this? On Thu, Nov 28, 2019 at 5:09 PM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes this was broken for me too, there was another post on here about this

On 2020-03-29, Nemanja Ivanovic via llvm-dev wrote: >Glad you got it working. >My suggestion about LLVM_ENABLE_THREADS didn't work because you didn't >apply it when building the build linker. > >When you don't have the ability to rebuild the build compiler, this doesn't >apply. In those cases, I end up doing a dirty hack where I use a wrapper >script with

Good news, I was able to use up to 37 cores for LLVM build with LLD. The build speed, did not measure precisely though, is comparable to the build with GNU ld case. Thank you all for your help! On Sun, Mar 29, 2020 at 5:04 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes unfortunately that would limit you to 4 cores. > > There’s no easy way to use lld with

That is slowing down the build visibly, for the speed I should stick with ld at the moment. On Sun, Mar 29, 2020 at 4:42 AM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > Would `taskset -c 0-3 ninja check-all -j4` work? > > > > *De :* Itaru Kitayama <itaru.kitayama at gmail.com> > *Envoyé :* March 28, 2020 3:37 PM > *À :* Alex Brachet-Mialot

Hello Alex, Thanks for the hint. It was actually not the -O flag that created the problem. But it pointed me in the right direction, when I passed -fno-experimental-new-pass-manager it started to show the error. My guess is that the new pass manager is more aggressive in removing UB? Thanks, Tobias On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot <alexbrachetmialot at gmail.com> wrote:

On 04/01/2020 01:47 PM, Itaru Kitayama via llvm-dev wrote: > Thanks for the heads up the supercomputer > Is down for maintenance this week. > I’ll give it a try when it gets back. > This doesn't look to me like it's necessarily an lld issue. Trying to build all the sub-projects without limiting the number of ninja jobs is almost guaranteed to run out of memory on a machine

This might not be the workaround you want because it is only available in C, but you can use restrict to allow such optimizations. https://godbolt.org/z/2gQ26f Alex On Thu, Aug 8, 2019 at 11:50 AM Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > char* scscx is an universal pointer and may point to anything, > including itself. That is, scscx might

$ free -g total used free shared buff/cache available Mem: 376 149 20 1 207 225 Swap: 3 0 3 Too small swap size for a 72-core login machine? On Sun, Mar 29, 2020 at 4:28 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Enable threads is for building llvm with

I'm not sure the idea that enabling pull requests will make it easier for new contributors is fully thought out. Just because more people might be familiar with GitHub, doesn't mean it is superior. I've found the workflow on Phabricator to be really easy. I think many people agree that Phabricator is really good, I don't think we would want to get rid of Phabricator and while its

My personal preference is that llvm-readelf only show the elf related options with -help and show all with -help-hidden. There is support for this in CommandLine.h, but I don't know how tricky it gets when we don't want them to be hidden for llvm-readobj. I haven't looked into this fully. For some reference, I have compiled how the other alias tools are handled. Many of these are

Hi Rui, all, Yesterday I brought the variable-renaming commits in to Sony's downstream LLD. We have a merge-based flow rather than continually rebasing our patch set, but it went reasonably smoothly nevertheless. The one snag I hit is that the tool initially missed variables mentioned in assert()s. I didn't put much time in to investigating this, but I presume it's because my

Good point, too. I believe I can find lines starting with `@parameter` and apply the same name conversion rules to identifiers after `@parameter`. Since lld doesn't use doxygen comments, it is fine for now, but before moving forward, I'll address that. Thank you for pointing that out. On Wed, Jul 10, 2019 at 8:20 PM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: >

On another login node which is 256 (GB)/48 (nodes) JURECA at JSC, I never had an LLD issue without setting -j when executing ninja in the past few weeks. On Thu, Apr 2, 2020 at 7:17 AM Itaru Kitayama <itaru.kitayama at gmail.com> wrote: > Tom, > Then what ratio do you think it’s minimal? > > On Thu, Apr 2, 2020 at 6:11 Tom Stellard <tstellar at redhat.com> wrote: >