Re: [PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

Yes, that's right. I think most errors are caught in Sema. There "if there is an error, the output should be suppressed" should be a consensus. For some auxiliary files it was a bit fuzzy to me. So I checked .dwo which is a similar auxiliary output - the output is suppressed with an error - so it

Re: [PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

It is rare to report an error in BackendUtil.cpp . So I checked the other Diags.Report instance and noticed that -split-dwarf-file a.dwo -split-dwarf-output a.dwo (when a.dwo is not writable) suppresses the output. So there is no reason that -fbasic-block-sections=list= should not follow the

Re: [PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

I checked chmod -w a.dwo; clang -cc1 -debug-info-kind=limited -dwarf-version=4 -split-dwarf-file a.dwo -split-dwarf-output a.dwo -emit-obj -o - split-debug-output.c which suppresses the output, so -fbasic-block-sections=list= should follow the convention as well. Sent

Re: [PATCH] D87921: Fix -funique-internal-linkage-names to work with -O2 and new pass manager

FWIW I tested check-msan in a -DCMAKE_BUILD_TYPE=Release build on a powerpc64le machine. All tests passed. I cannot connect the failure to the clang patch. On Mon, Sep 21, 2020 at 10:02 PM Sriraman Tallam wrote: > > On Mon, Sep 21, 2020 at 5:58 PM Matt Morehouse via Phabricator > wrote: > > > >

Re: [PATCH] D82225: [libTooling] Delete deprecated `Stencil` combinators.

On Thu, Jun 25, 2020 at 5:53 AM Yitzhak Mandelbaum wrote: > > Thanks for alerting me. Why is it important to strip out this information? > Also, might this be something we can change on the arcanist side (to not add > to the commit message) rather than strip out on the git end? Mostly to keep

Re: r371918 - [Driver] Fix multiple bugs related to dependency file options: -M -MM -MD -MMD -MT -MQ

It was related to D67542 It tried to solve some other problems. On Sun, Sep 15, 2019 at 1:40 AM Nico Weber wrote: > This looks similar to https://reviews.llvm.org/D67542 > > On Sat, Sep 14, 2019 at 1:59 AM Fangrui Song via cfe-commits < >

Re: r362067 - asm goto: fix out-of-bounds read of Constraints after rC362045

You beat me to it.. Reverted On Thu, May 30, 2019 at 5:41 PM Benjamin Kramer wrote: > Is this still necessary after r362062? > > On Thu, May 30, 2019 at 10:00 AM Fangrui Song via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: maskray >> Date: Thu May 30 01:03:02 2019 >> New

Re: r360403 - Change -gz and -Wa, --compress-debug-sections to use gABI compression (SHF_COMPRESSED)

It's fine :) The problem may be that users with older pre-2.26 binutils may have older GNU as as well. Their GNU as may not recognize --compress-debug-sections=zlib. On Wed, May 15, 2019 at 3:39 AM Eric Christopher wrote: > Hi Ray, > > I've temporarily reverted this here: > > echristo@jhereg

Re: [clang-tools-extra] r356849 - [pp-trace] Modernize the code

There was another change rCTE356893 which rewrote this part. On Tue, Mar 26, 2019 at 1:24 AM wrote: > > Hi, > > Yes, it appears to have been fixed as of r356878. > > http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/24580 > > Douglas Yung > > -Original

Re: [clang-tools-extra] r356849 - [pp-trace] Modernize the code

Is it fixed now? On Mon, Mar 25, 2019 at 7:25 AM wrote: > > Hi Fangrui, > > This change is causing the PS4 Windows bot to fail to build: > > http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/24560/steps/build/logs/stdio > > FAILED: >

Re: [PATCH] D50294: [Driver] Use -gdwarf-3 by default for FreeBSD

On 2018-09-25, Ed Maste via Phabricator wrote: emaste added a comment. I'm using this change: https://github.com/emaste/freebsd/commit/1c3deab6d518feb1a7e88de5b342a139e4022a21 In FreeBSD 12 and later we use Clang, lld, and ELF Tool Chain. (We still have gas and objdump from the outdated

Re: [PATCH] D51234: [Driver] Change MipsLinux default linker from "lld" to "ld.lld"

On 2018-08-27, Rui Ueyama via Phabricator wrote: ruiu added a comment. If this piece of code used to be working correctly, there is another piece of code that adds `-flavor ld` to the command line. But if that's the case, this change wouldn't work because it constructs something like "ld.lld

Re: r340709 - [Driver] Change MipsLinux default linker from "lld" to "ld.lld"

Thanks! On Mon, Aug 27, 2018 at 1:50 AM Chandler Carruth wrote: > > Build bots have been broken all day, so I'm trying a speculative fix in > r340727. If this doesn't work, i'll just revert all of this. > > On Sun, Aug 26, 2018 at 3:51 PM Chandler Carruth wrote: >> >> FYI, test cases also seem

Re: r338291 - Remove trailing space

On 2018-07-30, Aaron Ballman wrote: On Mon, Jul 30, 2018 at 4:43 PM, Fāng-ruì Sòng wrote: Does this apply to only public headers (include/llvm include/llvm-c include/clang ...) or everything? (lib/**/*.{cpp,h})? I've understood it applies to "everything" in that you should not commit

Re: r338291 - Remove trailing space

Maybe not too terrible for out-of-tree projects. If they use git mirror, `git rebase` is smart enough to ignore changing lines with trailing whitespace (if not, there is git rebase -Xignore-space-at-eol). Some editors are configured with highlighting trailing spaces and these spaces will turn to

Re: r338291 - Remove trailing space

Does this apply to only public headers (include/llvm include/llvm-c include/clang ...) or everything? (lib/**/*.{cpp,h})? On Mon, Jul 30, 2018 at 1:36 PM Aaron Ballman wrote: > > On Mon, Jul 30, 2018 at 4:24 PM, Michael Kruse > wrote: > > I think removing trailing space is a good thing. Some

Re: r338291 - Remove trailing space

Oops.. sorry but now they have been committed.. On Mon, Jul 30, 2018 at 12:31 PM Aaron Ballman wrote: > > This is an extraordinary amount of churn for very little value, IMO. > The same goes for r338291. Were these changes discussed somewhere > before being committed? I worry about the negative