similar to: Test failure due to file path

For ignore-undefined-symbols.s, the simplest fix ought to be to have the llvm-mc RUN line take the source from <stdin>: # RUN: llvm-mc –filetype=obj –triple=x86_64-pc-linux %s –o %t.o –g becomes # RUN: llvm-mc –filetype=obj –triple=x86_64-pc-linux < %s –o %t.o –g But in this case, llvm-symbolizer still prints the file as $CWD/<stdin> which seems like its own separate bug. --paulr

******************** FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) ******************** TEST 'LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s' FAILED ******************** Script: -- /home/csabaraduly/wk/LLVM/build_release/bin/llvm-mc -triple x86_64-pc-linux /home/csabaraduly/wk/LLVM/llvm/test/tools/llvm-dwarfdump/X86/debug-names-find.s -filetype=obj -o

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at

Hello Csaba, Thanks for the heads up. I am the one who wrote that test. I'll look into that shortly. Sorry about the trouble. pl On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ******************** > FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) > ******************** TEST 'LLVM :: >

Hi all, I'm trying to build clang on Ubuntu 17.10 - the build succeeds, but testing fails: ~/wk/LLVM/build_release$ svn info ../llvm/ Path: /home/csabaraduly/wk/LLVM/llvm Working Copy Root Path: /home/csabaraduly/wk/LLVM/llvm URL: https://llvm.org/svn/llvm-project/llvm/trunk Relative URL: ^/llvm/trunk Repository Root: https://llvm.org/svn/llvm-project Repository UUID:

On Tue, Nov 28, 2017 at 12:16 AM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Mon, Nov 27, 2017 at 4:56 AM, Csaba Raduly via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm trying to build clang on Ubuntu 17.10 - the build succeeds, but >> testing fails: >> >> ~/wk/LLVM/build_release$

I guess there is lots of stuff that you don't care about besides tsan/go that is built and tested during llvm build, and there is no way to selectively disable each one of that. By design. In the long run we need to fix all failures (please file a proper bug). If you are looking for a temporal workaround, then comment it out. I don't what else to suggest. On Tue, Nov 28, 2017 at 9:47 AM,

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

Many llvm utilities use cl::ParseCommandLineOptions() (include/Support/CommandLine.h) to parse command line options. The cl library accepts both -long-option and --long-option forms, with the single dash form (-long-option) being more popular. We also have many binary utilities (llvm-objcopy llvm-objdump llvm-readobj llvm-size ...) whose names reflect what they imitate. For compatibility with GNU

> Are you proposing to make this the new style across all LLVM utilities? No. Only drop --long-option for GNU binutils replacements (people sometimes call them LLVM binary utilities): llvm-objcopy (D60439), llvm-ar, llvm-size, llvm-nm, etc. llvm-objdump (not sure what to do with mach-o specific dump options), llvm-readelf (not sure what to do with llvm-readobj) On Sat, Apr 20, 2019 at 2:13 AM

For binutil compatibility, and in general for any new tools, this sounds reasonable to me. But I'd worry that things like llvm-readobj have existed for a long time and people are used to flags like "-sections", and it may be complicated to change that now. (I guess this RFC is a check to see if this is true for anyone on the mailing list). What happens if you make this change and

It's actually a bit weirder than you might think. The CommandLine parser will happily eat as many dashes as you care to write, e.g., `----sections` is the same as `-sections`. On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As I think I said elsewhere, I find it weird that LLVM tools accept long > arguments with a single dash,

> Here are my suggestions for the minimal set of tags: > > + 1 per LLVM backend > + 1 per top-level directory in https://github.com/llvm/llvm-project > > I think if we start here we can create more specialized tags as > GitHub issues gets more traffic and we have more experience using it. The google doc I created contains the slightly cleaned list of current components. It

Dear llvm developpers, I followed the tutorial to build llvm and clang provided here: https://clang.llvm.org/get_started.html The sources are in sync with subversion repository, and I ended up with more than 30GB of binaries in llvm/bin as shown at the end of this message. I assume I did something wrong, but I did not find any entry in the doc that helps me understand how to reduce the size of

I'm seeing a bunch of failures on AArch64 after updating this morning. These are NOT failing on x86-64. These all seem to be caused by segfaults (example backtrace below). Is anyone else seeing this? -David LLVM :: DebugInfo/symbolize-no-debug-str.test LLVM :: tools/gold/X86/comdat.ll LLVM :: tools/gold/X86/visibility.ll LLVM ::

On Thu, Feb 6, 2020 at 9:15 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > On Thu, 6 Feb 2020 at 00:24, Jon Chesterfield via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This doesn't sound right. GNU binutils have a large quantity of legacy >> cruft, not least the redundancy between tools like readelf and objdump >> which are

On Wed, Mar 7, 2018 at 9:56 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Zach! > > I've been thinking a bit about this for a while now and I'm still of two > opinions: > > On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Currently llvm-objcopy only supports ELF

On Fri, Jan 19, 2018 at 1:02 PM Leonardo Santagada <santagada at gmail.com> wrote: > On Fri, Jan 19, 2018 at 9:44 PM, Zachary Turner <zturner at google.com> > wrote: > >> >> >> On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <santagada at gmail.com> >> wrote: >> >>> Hi, >>> >>> No I didn't, I used cl.exe

Hi, On 03/20/2018 06:05 AM, Eric Christopher wrote: > > > On Fri, Mar 16, 2018 at 1:57 AM Paul Semel <semelpaul at gmail.com > <mailto:semelpaul at gmail.com>> wrote: > > Hi Eric, > > > On 03/15/2018 04:33 PM, Eric Christopher wrote: >> Hi Paul, >> >> >> >> I'm also interested in the command line

Hi Zach! I've been thinking a bit about this for a while now and I'm still of two opinions: On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Currently llvm-objcopy only supports ELF files, and most of it's command > line flags are ELF / DWARF specific that don't make any sense on COFF > files. So a useful set of