Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-03 Thread Hans Wennborg via lldb-dev 
On Fri, Jan 31, 2020 at 9:37 PM Dimitry Andric  wrote:
>
> On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers 
>  wrote:
> >
> > It took a bit longer than planned due to master being a somewhat
> > unstable at the branch point, but Release Candidate 1 has now been
> > tagged as llvmorg-10.0.0-rc1.
>
> For this rc, I used three patches, which are attached.
>
> Main results on amd64-freebsd11 (I will post i386 results as they become
> available):
>
>   Expected Passes: 67894
>   Expected Failures  : 268
>   Unsupported Tests  : 4653
>   Unexpected Passes  : 5
>   Unexpected Failures: 541
>   Individual Timeouts: 18
>
> Uploaded:
> SHA256 (clang+llvm-10.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
> 751f2d86eede35a201db524a78ebb0e9d48b71d120b44153f961edb666d30c96

Thanks! I've added it to the pre-release page and also to the github release.

>
> Unfortunately the test-suite did not build at all, as all the Bitcode
> compilations failed with segfaults, similar to the following run under
> gdb:
>
> Starting program: 
> /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
>  -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT 
> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
>  -MF 
> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d
>  -o 
> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
>  -c 
> /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0001000f in ?? ()
> (gdb) bt
> #0  0x0001000f in ?? ()
> #1  0x028ca9c0 in 
> llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
> #2  0x02e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) 
> ()
> #3  0x02e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
> #4  0x02e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
> #5  0x035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
> const&, llvm::Module*, clang::BackendAction, 
> std::__1::unique_ptr std::__1::default_delete >) ()
> #6  0x03c17e67 in clang::CodeGenAction::ExecuteAction() ()
> #7  0x03b7abca in clang::FrontendAction::Execute() ()
> #8  0x03aea761 in 
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
> #9  0x03c12905 in 
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
> #10 0x01cbaf0e in cc1_main(llvm::ArrayRef, char const*, 
> void*) ()
> #11 0x01cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl&) 
> ()
> #12 0x039eb297 in void llvm::function_ref ()>::callback_fn
>  >, std::__1::basic_string, 
> std::__1::allocator >*, bool*) const::$_1>(long) ()
> #13 0x033e406a in 
> llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) ()
> #14 0x039ea7f0 in 
> clang::driver::CC1Command::Execute(llvm::ArrayRef
>  >, std::__1::basic_string, 
> std::__1::allocator >*, bool*) const ()
> #15 0x039bfc5c in 
> clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, 
> clang::driver::Command const*&) const ()
> #16 0x039c01ac in 
> clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, 
> llvm::SmallVectorImpl >&) 
> const ()
> #17 0x039d336c in 
> clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, 
> llvm::SmallVectorImpl >&) 
> ()
> #18 0x01cb884f in main ()
>
> Looks like the bitcode compilation path is totally busted?  Anybody know
> an open bug for this?

I haven't seen one, but I'm behind on email. Can you please file one
to make sure this gets tracked?

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-03 Thread Hans Wennborg via lldb-dev 
On Fri, Jan 31, 2020 at 9:51 PM Michał Górny  wrote:
>
> On Thu, 2020-01-30 at 14:38 -0500, Hans Wennborg via Release-testers
> wrote:
> >
> Please file bug reports for any issues you find as blockers of
> > https://llvm.org/pr44555
> >
> > Release testers: please start your engines, run the script, share your
> > results, and upload binaries.
> >
>
> Gentoo/amd64 issues (with 32-bit multilib where available):
>
> - libc++ stand-alone builds were broken; revert was committed
>   as 3573526c028;  with that patch, all tests pass for me.
>
> - there's one openmp issue on 32-bit build:
>   https://bugs.llvm.org/show_bug.cgi?id=44733
>
> - I've found an LLDB bug with linking liblldb.so in tests.
>   I don't think it's strictly a regression but I don't recall noticing
>   it before.  I've started working on a patch:
>   https://reviews.llvm.org/D73767
>
>   However, I'm not sure if it's worth backporting.  There's still
>   a plethora of failing tests, plus some lit bug causing it to hang
>   at the end, and I don't think I'll find time to look into any of this
>   anytime soon.

Thanks for digging into these issues!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

2020-02-03 Thread James Henderson via lldb-dev 
I'm happy to test things out, as long as it's not too much of a time sink
(I have a lot on my plate at the moment, so something that takes more than
the odd few minutes here and there may not be feasible).

On Sat, 1 Feb 2020 at 02:10, Fangrui Song  wrote:

> On 2020-01-31, Tom Stellard via llvm-dev wrote:
> >On 01/31/2020 01:21 AM, James Henderson wrote:
> >> My only concern is the ability to get auto-subscribed onto issues for
> specific tools (i.e. the setup I currently have). If that can be resolved
> in a satisfactory manner, then I'm all for this (although less than two
> weeks seems like a rather ambitious time to switch over...). If it can't,
> then I'd be opposed to switching at all.
> >>
> >
> >Would you be able to help me test some potential solutions for this?
>
> My feeling is similar to James'.
>
> +1 if auto subscription is available (similar to Herald rules).
> -1 if it isn't.
>
> And I guess contributors may need to change the notification setting from
> "Watching" to "Not watching",
> to avoid issue spam.
>
>
> Tom, I'd like to be a tester.
>
> >
> >> On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org > wrote:
> >>
> >> On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> >> > Hi,
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org   cfe-...@lists.llvm.org >> wrote:
> >> >
> >> > On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >> > > We held a round-table at the llvm dev conference about what
> other pieces of Github infrastructure we may want to use. This thread in
> particular is about switching to github issue tracking. Use of other parts
> of Github functionality was also discussed -- but that should be for other
> email threads.
> >> > >
> >> > > Most of the ideas here were from other people. I /believe/
> this proposal represents the overall feeling of the folks at the
> round-table, in spirit if not in exact details, but nobody else has
> reviewed this text, so I can't make any specific such claim as to who the
> "we" represents, other than myself. Just assume all the good ideas here
> were from others, and all the bad parts I misremembered or invented.
> >> > >
> >> > >
> >> >
> >> > Hi,
> >> >
> >> > I want to restart this discussion.  There seemed to be
> support for this,
> >> > but we got held up trying to decide on the appropriate set of
> tags to
> >> > use to classify issues.
> >> >
> >> > I propose that we move forward with this proposal and disable
> creation of
> >> > new bugs in bugzilla on Feb 11, and require all new bugs be
> filed via GitHub
> >> > issues from that date forward.
> >> >
> >> > I think that for choosing the tags to use, we should just
> take requests
> >> > from the community over the next week and add whatever is
> asked for.  The main
> >> > purpose of adding tags is so we can setup cc lists for bugs,
> so I think this
> >> > is a good way to ensure that we have tags people care about.
> We can always
> >> > add more tags later if necessary.
> >> >
> >> >
> >> > Do we have a way for individuals to get individually
> automatically subscribed on all the bugs created for a given tag?
> >> > Mailing-lists seem fairly rigid in terms of granularity with
> respect to tags.
> >> >
> >>
> >> When I said cc lists, I really meant auto-subscribe lists, I didn't
> mean
> >> that we would start sending issue emails to mailing lists.
> >>
> >> From what I can tell, there are a couple different ways to
> auto-subscribe
> >> people using github actions.  I think the most simple would be to
> use
> >> the assignee field, but I think it's also possible by @ mentioning
> people
> >> directly in a comment or @ mentioning teams.
> >>
> >> I was planning to experiment more with this over the next few days.
> >>
> >> -Tom
> >>
> >>
> >>
> >>
> >>
> >> > --
> >> > Mehdi
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > What does everyone think about this?
> >> >
> >> > -Tom
> >> >
> >> >
> >> > > Background
> >> > > 
> >> > > Our bugzilla installation is...not great. It's been
> not-great for a long time now.
> >> > >
> >> > > Last year, I argued against switching to github issues. I
> was somewhat optimistic that it was possible to improve our bugzilla in
> some incremental ways...but we haven't. Additionally, the upstream bugzilla
> project was supposed to make a new release of bugzilla ("harmony"), based
> on bugzilla.mozilla.org  <
> http://bugzilla.mozilla.org> 's fork, which

[lldb-dev] [Bug 44760] New: stop-hook doesn't work when user make ctrl-c interrupt

2020-02-03 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=44760

Bug ID: 44760
   Summary: stop-hook doesn't work when user make ctrl-c interrupt
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: slei.cas...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

lldb doesn't consider stop-hook when user make ctrl-c interrupt.
step to reproduce:
1. write the following content to /tmp/a.py
```
def __lldb_init_module(debugger, internal_dict):
debugger.HandleCommand('target stop-hook add --one-liner "register read
rax"')
```
2. debug any program with the following lldb command
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) command script import "/tmp/a.py"
Stop hook #1 added.
(lldb) r
 rax = 0x

Process 9563 launched: '/tmp/a.out' (x86_64)
Process 9563 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x7fff6b9babba libsystem_kernel.dylib`__semwait_signal + 10
libsystem_kernel.dylib`__semwait_signal:
->  0x7fff6b9babba <+10>: jae0x7fff6b9babc4; <+20>
0x7fff6b9babbc <+12>: movq   %rax, %rdi
0x7fff6b9babbf <+15>: jmp0x7fff6b9b968d; cerror
0x7fff6b9babc4 <+20>: retq
Target 0: (a.out) stopped.



expected: after user make ctrl-c interrupt, lldb should print rax register, but
lldb doesn't print it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

2020-02-03 Thread Jacob Lifshay via lldb-dev 
On Mon, Feb 3, 2020, 09:00 Michael Kruse  wrote:

> Am Do., 30. Jan. 2020 um 13:29 Uhr schrieb Jacob Lifshay via cfe-dev
> :
> >
> > On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I want to restart this discussion.  There seemed to be support for this,
> >> but we got held up trying to decide on the appropriate set of tags to
> >> use to classify issues.
> >>
> >> I propose that we move forward with this proposal and disable creation
> of
> >> new bugs in bugzilla on Feb 11, and require all new bugs be filed via
> GitHub
> >> issues from that date forward.
> >>
> >> I think that for choosing the tags to use, we should just take requests
> >> from the community over the next week and add whatever is asked for.
> The main
> >> purpose of adding tags is so we can setup cc lists for bugs, so I think
> this
> >> is a good way to ensure that we have tags people care about.  We can
> always
> >> add more tags later if necessary.
> >>
> >> What does everyone think about this?
> >
> >
> > Before disabling Bugzilla, I think there should be a way for those who
> don't have/want github accounts to create/comment-on bug reports (maybe a
> mailing list with a thread per bug?). Once that's done, I'm all for
> switching to github.
>
> This adds a burden on everyone to observe two locations for bugs. By
> comparison creating a GitHub account is simple. Even creating a
> bugzilla account is more difficult.
>

I think it should be relatively easy to automate using github's APIs.

The issue is not the ease of signing up for github, but that there are some
people who specifically don't have or want GitHub accounts because they
don't want to use proprietary software or were prevented by GitHub's rules
(Iran or similar places, don't know that we would legally be able to post
on GitHub on their behalf though).

I personally don't have either issue, but do know some people with the
former issue who are using LLVM as part of their job.

Jacob
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-03 Thread Dimitry Andric via lldb-dev 
On 3 Feb 2020, at 10:57, Hans Wennborg  wrote:
> 
> On Fri, Jan 31, 2020 at 9:37 PM Dimitry Andric  wrote:
...
>> Unfortunately the test-suite did not build at all, as all the Bitcode
>> compilations failed with segfaults, similar to the following run under
>> gdb:
>> 
>> Starting program: 
>> /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
>>  -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT 
>> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
>>  -MF 
>> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d
>>  -o 
>> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
>>  -c 
>> /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0001000f in ?? ()
>> (gdb) bt
>> #0  0x0001000f in ?? ()
>> #1  0x028ca9c0 in 
>> llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
>> #2  0x02e8edc0 in 
>> llvm::FPPassManager::runOnFunction(llvm::Function&) ()
>> #3  0x02e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
>> #4  0x02e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) 
>> ()
>> #5  0x035de7dc in 
>> clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
>> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
>> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
>> const&, llvm::Module*, clang::BackendAction, 
>> std::__1::unique_ptr> std::__1::default_delete >) ()
>> #6  0x03c17e67 in clang::CodeGenAction::ExecuteAction() ()
>> #7  0x03b7abca in clang::FrontendAction::Execute() ()
>> #8  0x03aea761 in 
>> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
>> #9  0x03c12905 in 
>> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
>> #10 0x01cbaf0e in cc1_main(llvm::ArrayRef, char const*, 
>> void*) ()
>> #11 0x01cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl> const*>&) ()
>> #12 0x039eb297 in void llvm::function_ref> ()>::callback_fn
>>  >, std::__1::basic_string, 
>> std::__1::allocator >*, bool*) const::$_1>(long) ()
>> #13 0x033e406a in 
>> llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) ()
>> #14 0x039ea7f0 in 
>> clang::driver::CC1Command::Execute(llvm::ArrayRef
>>  >, std::__1::basic_string, 
>> std::__1::allocator >*, bool*) const ()
>> #15 0x039bfc5c in 
>> clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, 
>> clang::driver::Command const*&) const ()
>> #16 0x039c01ac in 
>> clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, 
>> llvm::SmallVectorImpl >&) 
>> const ()
>> #17 0x039d336c in 
>> clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, 
>> llvm::SmallVectorImpl >&) 
>> ()
>> #18 0x01cb884f in main ()
>> 
>> Looks like the bitcode compilation path is totally busted?  Anybody know
>> an open bug for this?
> 
> I haven't seen one, but I'm behind on email. Can you please file one
> to make sure this gets tracked?

Filed .  I didn't have a
debug build of clang, so not a really informative backtrace yet.

I suppose the pre-supplied .bc files don't really get processed well by
recent versions of clang.  I hope that others can reproduce this.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev