Mailing lists matching lists.llvm.org
cfe-commits lists.llvm.orglldb-commits lists.llvm.org
llvm-branch-commits lists.llvm.org
llvm-bugs lists.llvm.org
Re: [lldb-dev] [cfe-dev] [llvm-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?
On 4/16/21 2:31 AM, Omair Javaid wrote:
On Wed, 14 Apr 2021 at 20:41, Tom Stellard mailto:tstel...@redhat.com>> wrote:
On 4/14/21 5:50 AM, Omair Javaid wrote:
> Ping!
>
> Tom, any update on this?
>
Yes, thanks for reminding me. The infrastructure is in place now, so
we can start adding more bots. Do you have a bot that you want to add?
-Tom
I intend to set up two new release bots for LLVM AArch64 and Arm release. Do
you have a reference release bot that I can replicate for my use-case?
The release bots are listed in this file:
https://github.com/llvm/llvm-zorg/blob/main/buildbot/osuosl/master/config/release_builders.py
-Tom
> On Mon, 15 Feb 2021 at 20:02, Nemanja Ivanovic mailto:nemanja.i@gmail.com> <mailto:nemanja.i@gmail.com
<mailto:nemanja.i@gmail.com>>> wrote:
>
> We are interested in doing this for PPC as well. Not likely for all
of our bots, but one or two select ones.
>
> On Fri, Feb 12, 2021 at 11:51 AM Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>>> wrote:
>
> On 2/12/21 1:49 AM, Omair Javaid wrote:
> > Hi Tom,
> >
> > We at Linaro are maintaining LLVM Arm/AArch64 buildbots and
want a host buildbot for testing of release branches.
> >
>
> OK, that's great.
>
> > Kindly share the steps to do this. Do we have to host
separate builbots for tracking release branches or is it possible to track multiple
branches by existing buildbots assuming traffic on release branches is less frequent?
> >
>
> I've submitted a patch[1] to add the infrastructure for enabling
builders
> on the release branch. Once this patch or something similar
gets applied
> then we can start enabling individual builders. I'll follow up
with you
> once this patch lands.
>
> -Tom
>
>
> [1] https://reviews.llvm.org/D96046 <https://reviews.llvm.org/D96046>
<https://reviews.llvm.org/D96046 <https://reviews.llvm.org/D96046>>
>
> > On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org> <mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>>
<mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> <mailto:llvm-...@lists.llvm.org
<mailto:llvm-...@lists.llvm.org>>>> wrote:
> >
> > On 2/2/21 1:23 AM, Diana Picus wrote:
> > > Hi Tom,
> > >
> > > This sounds interesting! Would this also make it
possible to automatically get the release binaries from the buildbots, as opposed to
manually uploading to the FTP server?
> > >
> >
> > Yes, this is something I would like to do. I think you
could pretty easily run
> > the test-release.sh script on the bot. The only issue is
finding a way to
> > securely upload the binaries.
> >
> > -Tom
> >
> > > Cheers,
> > > Diana
> > >
> > > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>>> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>>>>> wrote:
> > >
> > > Hi,
> > >
> > > I would like to improve the testing coverage in
the release branch, so if you
> > > are a buildbot owner and would like to enable your
builder for the release branch,
> > > let me know, and I can help get it enabled.
> > >
> > > Also, if you have any ideas for some more
extensive testing that might be too
> > > slow to run on the
Re: [lldb-dev] [cfe-dev] [llvm-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?
On Wed, 14 Apr 2021 at 20:41, Tom Stellard wrote: > On 4/14/21 5:50 AM, Omair Javaid wrote: > > Ping! > > > > Tom, any update on this? > > > > Yes, thanks for reminding me. The infrastructure is in place now, so > we can start adding more bots. Do you have a bot that you want to add? > > -Tom > I intend to set up two new release bots for LLVM AArch64 and Arm release. Do you have a reference release bot that I can replicate for my use-case? > > On Mon, 15 Feb 2021 at 20:02, Nemanja Ivanovic <mailto:nemanja.i@gmail.com>> wrote: > > > > We are interested in doing this for PPC as well. Not likely for all > of our bots, but one or two select ones. > > > > On Fri, Feb 12, 2021 at 11:51 AM Tom Stellard via cfe-dev < > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> wrote: > > > > On 2/12/21 1:49 AM, Omair Javaid wrote: > > > Hi Tom, > > > > > > We at Linaro are maintaining LLVM Arm/AArch64 buildbots and > want a host buildbot for testing of release branches. > > > > > > > OK, that's great. > > > > > Kindly share the steps to do this. Do we have to host > separate builbots for tracking release branches or is it possible to track > multiple branches by existing buildbots assuming traffic on release > branches is less frequent? > > > > > > > I've submitted a patch[1] to add the infrastructure for enabling > builders > > on the release branch. Once this patch or something similar > gets applied > > then we can start enabling individual builders. I'll follow up > with you > > once this patch lands. > > > > -Tom > > > > > > [1] https://reviews.llvm.org/D96046 < > https://reviews.llvm.org/D96046> > > > > > On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>>> wrote: > > > > > > On 2/2/21 1:23 AM, Diana Picus wrote: > > > > Hi Tom, > > > > > > > > This sounds interesting! Would this also make it > possible to automatically get the release binaries from the buildbots, as > opposed to manually uploading to the FTP server? > > > > > > > > > > Yes, this is something I would like to do. I think you > could pretty easily run > > > the test-release.sh script on the bot. The only issue is > finding a way to > > > securely upload the binaries. > > > > > > -Tom > > > > > > > Cheers, > > > > Diana > > > > > > > > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev < > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>>> wrote: > > > > > > > > Hi, > > > > > > > > I would like to improve the testing coverage in > the release branch, so if you > > > > are a buildbot owner and would like to enable your > builder for the release branch, > > > > let me know, and I can help get it enabled. > > > > > > > > Also, if you have any ideas for some more > extensive testing that might be too > > > > slow to run on the main branch, we may be able to > enable it on the release > > > > branch either running once per commit or once per > tag. > > > > > > > > Thanks, > > > > Tom > > > > > > > > ___ > > > > cfe-dev mailing list > > > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>
Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week
On 10/16/19 5:51 PM, Mehdi AMINI via llvm-dev wrote:
On Wed, Oct 16, 2019 at 5:46 PM Tom Stellard <mailto:tstel...@redhat.com>> wrote:
On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> +1. And put it in the email (subject?). While it’s possible to
derive a count from a hash manually, better to have it in the
email in the first place. You can’t rely on
order-of-email-delivery to reflect order-of-commit.
>
I spent some time today looking into what it would take to add the
commit
number into the email. Implementing this will add some extra
complexity to the
emailer script and add another point of failure for us. We also
can't guarantee to always have it since at some point we may want
to start using
github's standard commit emails.
I think we should just wait and see how things go without having
a commit number in the email. It's easy to generate the number
locally from a git hash if needed. If it becomes a major
inconvenience
to not have it in the email, we can always look at adding it in later.
Having to get an up-to-date local clone and run commands to be able to
reason about the logical relationship between commits (does this build
failure email from a slow bot comes from before or after I landed my
revert?) seems to me like a non-trivial workflow regression. I would
personally be OK to increase the tooling complexity to preserve this.
+1 on this, but it's worth clarifying this is definitely not a blocker.
Just a nice to have which can easily be done after the switch if needed.
The best way to prove or disprove this is likely do what you suggest
though, and live through this for some time :)
--
Mehdi
-Tom
> --paulr
>
>
>
> *From:* llvm-dev mailto:llvm-dev-boun...@lists.llvm.org>> *On Behalf Of *Shoaib
Meenai via llvm-dev
> *Sent:* Wednesday, October 16, 2019 1:42 AM
> *To:* tstel...@redhat.com <mailto:tstel...@redhat.com>; Mehdi
AMINI mailto:joker@gmail.com>>
> *Cc:* llvm-dev mailto:llvm-...@lists.llvm.org>>; cfe-dev mailto:cfe-...@lists.llvm.org>>; openmp-dev
(openmp-...@lists.llvm.org <mailto:openmp-...@lists.llvm.org>)
mailto:openmp-...@lists.llvm.org>>;
LLDB Dev mailto:lldb-dev@lists.llvm.org>>
> *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
>
>
>
> I thought we were just going to count commits on a particular
branch and use the (branch name, commit count) tuple as our
monotonic incrementing identifier?
https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
>
>
>
>
>
> *From: *cfe-dev mailto:cfe-dev-boun...@lists.llvm.org>
<mailto:cfe-dev-boun...@lists.llvm.org
<mailto:cfe-dev-boun...@lists.llvm.org>>> on behalf of cfe-dev
mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>>
> *Organization: *Red Hat
> *Reply-To: *"tstel...@redhat.com <mailto:tstel...@redhat.com>
<mailto:tstel...@redhat.com <mailto:tstel...@redhat.com>>"
mailto:tstel...@redhat.com>
<mailto:tstel...@redhat.com <mailto:tstel...@redhat.com>>>
> *Date: *Tuesday, October 15, 2019 at 10:13 PM
> *To: *Mehdi AMINI mailto:joker@gmail.com> <mailto:joker@gmail.com
<mailto:joker@gmail.com>>>
> *Cc: *llvm-dev mailto:llvm-...@lists.llvm.org> <mailto:llvm-...@lists.llvm.org
<mailto:llvm-...@lists.llvm.org>>>, cfe-dev
mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>>,
"openmp-dev (openmp-...@lists.llvm.org
<mailto:openmp-...@lists.llvm.org>
<mailto:openmp-...@lists.llvm.org
<mailto:openmp-...@lists.llvm.org>>)" mailto:openmp-...@lists.llvm.org>
<mailto:openmp-...@lists.llvm.org
<mailto:openmp-...@lists.llvm.org>>>, LLDB Dev
mailto:lldb-dev@lists.llvm.org>
<mailto:lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>>>
> *Subject: *Re: [cfe-dev] Mailing list changes this week
>
>
>
> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
>
> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard
mailto:tstel...@redhat.com>
<mailto:tstel...@redhat.com <mailto:tstel...@redhat.com>>
<mailto:tstel...@redhat.com <mailto:tstel...@redhat.com>>
<mailto:tstel...@redhat.com <mailto:tstel...@redhat.com>%3e>> wrote:
>
> On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
>
> > Hi Tom.
>
> >
Re: [lldb-dev] [cfe-dev] [llvm-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?
On 4/14/21 5:50 AM, Omair Javaid wrote:
Ping!
Tom, any update on this?
Yes, thanks for reminding me. The infrastructure is in place now, so
we can start adding more bots. Do you have a bot that you want to add?
-Tom
On Mon, 15 Feb 2021 at 20:02, Nemanja Ivanovic mailto:nemanja.i@gmail.com>> wrote:
We are interested in doing this for PPC as well. Not likely for all of our
bots, but one or two select ones.
On Fri, Feb 12, 2021 at 11:51 AM Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote:
On 2/12/21 1:49 AM, Omair Javaid wrote:
> Hi Tom,
>
> We at Linaro are maintaining LLVM Arm/AArch64 buildbots and want a
host buildbot for testing of release branches.
>
OK, that's great.
> Kindly share the steps to do this. Do we have to host separate
builbots for tracking release branches or is it possible to track multiple
branches by existing buildbots assuming traffic on release branches is less
frequent?
>
I've submitted a patch[1] to add the infrastructure for enabling
builders
on the release branch. Once this patch or something similar gets
applied
then we can start enabling individual builders. I'll follow up with you
once this patch lands.
-Tom
[1] https://reviews.llvm.org/D96046 <https://reviews.llvm.org/D96046>
> On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org> <mailto:llvm-...@lists.llvm.org
<mailto:llvm-...@lists.llvm.org>>> wrote:
>
> On 2/2/21 1:23 AM, Diana Picus wrote:
> > Hi Tom,
> >
> > This sounds interesting! Would this also make it possible to
automatically get the release binaries from the buildbots, as opposed to manually
uploading to the FTP server?
> >
>
> Yes, this is something I would like to do. I think you could
pretty easily run
> the test-release.sh script on the bot. The only issue is
finding a way to
> securely upload the binaries.
>
> -Tom
>
> > Cheers,
> > Diana
> >
> > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>
<mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>>>> wrote:
> >
> > Hi,
> >
> > I would like to improve the testing coverage in the
release branch, so if you
> > are a buildbot owner and would like to enable your
builder for the release branch,
> > let me know, and I can help get it enabled.
> >
> > Also, if you have any ideas for some more extensive
testing that might be too
> > slow to run on the main branch, we may be able to enable
it on the release
> > branch either running once per commit or once per tag.
> >
> > Thanks,
> > Tom
> >
> > ___________
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
<https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>>
> >
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
<mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>>
>
>
>
> --
> Omair Javaid
> www.linaro.org <http://www.linaro.org> <http://www.linaro
Re: [lldb-dev] [cfe-dev] LLVM 9.0.1-final has been tagged
On 01/14/2020 08:59 AM, Russell Gallop wrote: > Hi Tom, Hans, > > I can't see LLVM-9.0.1-win*.exe from Hans on the GitHub release page > (https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1). Is this > still in progress? > Hans did you upload these? I don't see them on the server. -Tom > Thanks > Russ > > On Thu, 9 Jan 2020 at 20:05, Tom Stellard via cfe-dev <mailto:cfe-...@lists.llvm.org>> wrote: > > On 01/09/2020 09:11 AM, Brian Cain wrote: > > > > > > On Thu, Jan 9, 2020 at 12:29 AM Tom Stellard <mailto:tstel...@redhat.com> <mailto:tstel...@redhat.com > <mailto:tstel...@redhat.com>>> wrote: > > > > On 01/08/2020 09:24 AM, Brian Cain wrote: > > > Tom, the 9.0.1 final binaries didn't (yet?) make it to the github > release page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1 > > > > > > > The binaries have been posted now. > > > > > > I don't see the ubuntu 16 one that I uploaded there - > clang+llvm-9.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz > > > > These are up now. > > -Tom > > > > > > > > I also checked https://releases.llvm.org/ because I recall some > debate or back-and-forth about where the releases should go and/or redirects > or links from one to the other. But they're not there either. > > > > > > > I'm working on fixing the releases.llvm.org > <http://releases.llvm.org> <http://releases.llvm.org> page. > > > > -Tom > > > > > On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev > mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>>> wrote: > > > > > > Hi, > > > > > > I've just tagged the 9.0.1-final release. Testers can begin > uploading binaries. > > > > > > -Tom > > > > > > ___ > > > cfe-dev mailing list > > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > > > > > -- > > > -Brian > > > > > > > > -- > > -Brian > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [llvm-dev] Upgrading phabricator
One of the new “feature” is that emails are HTML only right now. Not quite nice for the archive (or for interacting by email). See for instance: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html (Also the funky "[Changed Subscribers] “ in the title) Another issue is that we can’t delete unposted inline comment anymore. — Mehdi > On Sep 29, 2016, at 9:35 PM, Zachary Turner via llvm-dev > wrote: > > You mentioned this was for an upgrade. Are there any major new features or > bugfixes to be aware of? > On Thu, Sep 29, 2016 at 9:26 PM Eric Liu via llvm-commits > mailto:llvm-comm...@lists.llvm.org>> wrote: > Hi all, > > Phabricator is (finally) back online! Let me know if you have any feedback or > problem :) > > Thanks, > Eric > > On Thu, Sep 29, 2016 at 10:23 PM Eric Liu <mailto:ioe...@google.com>> wrote: > According to top and iotop, mysqld is still working, and the progress bar did > move by a little bit, so I think it's just really slow. Apologies if this is > blocking you. > > On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > Still no word on when it will be back up? It's not hung is it? :D > > On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > >> On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev > <mailto:llvm-...@lists.llvm.org>> wrote: >> >> Sorry for blocking everyone for so long. > > No pb, thanks very much for taking care of it :) > >> It has been more than a year since the last upgrade, and mysql is adjusting >> schema for a table with ~150G data on a single VM instance. > > 150GB? I’m very surprised there is so much data in our phab! That seems > huge... > > My guess is that this includes all the diffs for every revision of every > review (as well as all the comments, etc), and it probably isn't as clever > with diffs as for example git. Which quite soon adds up to huge numbers when > you have tens of thousands of reviews. > > Purse speculation of course, I have never looked inside phabricator (or for > that matter, any other code-review tool). > > -- > Mats > > — > Mehdi > >> Sadly, the progress bar isn't giving useful information (plus I am not a >> good system admin), so I couldn't tell the ETA... >> >> FYI: According to previous maintainer, it takes a couple of hours for the >> last upgrade, so this should be done within a few hours (hopefully!). >> >> On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> Is there any ETA? >> >> -Krzysztof >> >> On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote: >> > That was a bad estimation. Database upgrade is taking time. >> > >> > On Thu, Sep 29, 2016 at 11:03 AM Eric Liu > > <mailto:ioe...@google.com> >> > <mailto:ioe...@google.com <mailto:ioe...@google.com>>> wrote: >> > >> > Hi all, >> > >> > Phabricator(reviews.llvm.org <http://reviews.llvm.org/> >> > <http://reviews.llvm.org <http://reviews.llvm.org/>>) will be down >> > for ~30 mins for an upgrade. Sorry for the short notice. >> > >> > Regards, >> > Eric >> > >> > >> > >> > ___ >> > LLVM Developers mailing list >> > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> > >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> hosted by The Linux Foundation >> _______ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> _______ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > ___ > LLVM Dev
Re: [lldb-dev] [Release-testers] [cfe-dev] LLVM 9.0.1-final has been tagged
On Tue, Jan 14, 2020 at 10:34 PM Tom Stellard via Release-testers wrote: > > On 01/14/2020 08:59 AM, Russell Gallop wrote: > > Hi Tom, Hans, > > > > I can't see LLVM-9.0.1-win*.exe from Hans on the GitHub release page > > (https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1). Is this > > still in progress? > > > > Hans did you upload these? I don't see them on the server. Oh no, I must have forgotten the actual upload step. Fixed that now. Thanks, Hans > > -Tom > > > Thanks > > Russ > > > > On Thu, 9 Jan 2020 at 20:05, Tom Stellard via cfe-dev > > mailto:cfe-...@lists.llvm.org>> wrote: > > > > On 01/09/2020 09:11 AM, Brian Cain wrote: > > > > > > > > > On Thu, Jan 9, 2020 at 12:29 AM Tom Stellard > <mailto:tstel...@redhat.com> <mailto:tstel...@redhat.com > > <mailto:tstel...@redhat.com>>> wrote: > > > > > > On 01/08/2020 09:24 AM, Brian Cain wrote: > > > > Tom, the 9.0.1 final binaries didn't (yet?) make it to the > > github release page > > https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1 > > > > > > > > > > The binaries have been posted now. > > > > > > > > > I don't see the ubuntu 16 one that I uploaded there - > > clang+llvm-9.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz > > > > > > > These are up now. > > > > -Tom > > > > > > > > > > > > I also checked https://releases.llvm.org/ because I recall some > > debate or back-and-forth about where the releases should go and/or > > redirects or links from one to the other. But they're not there either. > > > > > > > > > > I'm working on fixing the releases.llvm.org > > <http://releases.llvm.org> <http://releases.llvm.org> page. > > > > > > -Tom > > > > > > > On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev > > mailto:cfe-...@lists.llvm.org> > > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>>> wrote: > > > > > > > > Hi, > > > > > > > > I've just tagged the 9.0.1-final release. Testers can > > begin uploading binaries. > > > > > > > > -Tom > > > > > > > > ___ > > > > cfe-dev mailing list > > > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > > > > > > > > > -- > > > > -Brian > > > > > > > > > > > > -- > > > -Brian > > > > ___ > > cfe-dev mailing list > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > ___ > Release-testers mailing list > release-test...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Mailing list changes this week
On 10/16/2019 05:51 PM, Mehdi AMINI wrote: > > > On Wed, Oct 16, 2019 at 5:46 PM Tom Stellard <mailto:tstel...@redhat.com>> wrote: > > On 10/16/2019 07:23 AM, Robinson, Paul wrote: > > +1. And put it in the email (subject?). While it’s possible to derive > a count from a hash manually, better to have it in the email in the first > place. You can’t rely on order-of-email-delivery to reflect order-of-commit. > > > > I spent some time today looking into what it would take to add the commit > number into the email. Implementing this will add some extra complexity > to the > emailer script and add another point of failure for us. We also > can't guarantee to always have it since at some point we may want to > start using > github's standard commit emails. > > I think we should just wait and see how things go without having > a commit number in the email. It's easy to generate the number > locally from a git hash if needed. If it becomes a major inconvenience > to not have it in the email, we can always look at adding it in later. > > > Having to get an up-to-date local clone and run commands to be able to reason > about the logical relationship between commits (does this build failure email > from a slow bot comes from before or after I landed my revert?) seems to me > like a non-trivial workflow regression. I would personally be OK to increase > the tooling complexity to preserve this. > There are other ways to solve this, though, for example we could have the bots pass/fail the status checks for commits, so you could answer the question just by clicking the link in the email and looking at which checks have passed or failed. And I think overall this would be better than what we have now. I think there may be other cases like this were problems solved using the commit numbers may be able to be solved in different and better ways. Part of the reason to move to GitHub is to be able to take advantage of features like this, and I think continuing to use the commit numbers may hold us back a little from trying new things. > The best way to prove or disprove this is likely do what you suggest though, > and live through this for some time :) > Right, and I'm not sure we would even be able to get the changes done in time for the switch over anyway. -Tom > -- > Mehdi > > > > > > > -Tom > > > --paulr > > > > > > > > *From:* llvm-dev <mailto:llvm-dev-boun...@lists.llvm.org>> *On Behalf Of *Shoaib Meenai via > llvm-dev > > *Sent:* Wednesday, October 16, 2019 1:42 AM > > *To:* tstel...@redhat.com <mailto:tstel...@redhat.com>; Mehdi AMINI > mailto:joker....@gmail.com>> > > *Cc:* llvm-dev <mailto:llvm-...@lists.llvm.org>>; cfe-dev <mailto:cfe-...@lists.llvm.org>>; openmp-dev (openmp-...@lists.llvm.org > <mailto:openmp-...@lists.llvm.org>) <mailto:openmp-...@lists.llvm.org>>; LLDB Dev <mailto:lldb-dev@lists.llvm.org>> > > *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week > > > > > > > > I thought we were just going to count commits on a particular branch > and use the (branch name, commit count) tuple as our monotonic incrementing > identifier? > https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git > > > > > > > > > > > > *From: *cfe-dev <mailto:cfe-dev-boun...@lists.llvm.org> > <mailto:cfe-dev-boun...@lists.llvm.org > <mailto:cfe-dev-boun...@lists.llvm.org>>> on behalf of cfe-dev > mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> > > *Organization: *Red Hat > > *Reply-To: *"tstel...@redhat.com <mailto:tstel...@redhat.com> > <mailto:tstel...@redhat.com <mailto:tstel...@redhat.com>>" > mailto:tstel...@redhat.com> <mailto:tstel...@redhat.com > <mailto:tstel...@redhat.com>>> > > *Date: *Tuesday, October 15, 2019 at 10:13 PM > > *To: *Mehdi AMINI mailto:joker@gmail.com> > <mailto:joker@gmail.com <mailto:joker@gmail.com>>> > > *Cc: *llvm-dev <mailto:llvm-...@lists.llvm.org> <mailto:llvm-...@lists.llvm.org > <mailto:llvm-...@lists.llvm.org>>>, cfe-dev <mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org > <mailto:cfe-...@lists.llvm.org>>>, "openmp-dev (openmp-...@lists.llvm.org > <mailto:openmp-...@lists.llvm.org> <mailto:ope
Re: [llvm-dev] Upgrading phabricator
It looks like the new phabricator sends html email by default.
I personally prefer text email. What do others think? Is this configurable in
the new installation?
Thanks,
-- Sanjoy
Zachary Turner via llvm-commits wrote:
You mentioned this was for an upgrade. Are there any major new features or
bugfixes to be aware of?
On Thu, Sep 29, 2016 at 9:26 PM Eric Liu via llvm-commits
mailto:llvm-comm...@lists.llvm.org>> wrote:
Hi all,
Phabricator is (finally) back online! Let me know if you have any feedback
or problem :)
Thanks,
Eric
On Thu, Sep 29, 2016 at 10:23 PM Eric Liu mailto:ioe...@google.com>> wrote:
According to top and iotop, mysqld is still working, and the progress
bar did move by a little bit, so I think
it's just really slow. Apologies if this is blocking you.
On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
Still no word on when it will be back up? It's not hung is it? :D
On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
Sorry for blocking everyone for so long.
No pb, thanks very much for taking care of it :)
It has been more than a year since the last upgrade, and
mysql is adjusting schema for a table
with ~150G data on a single VM instance.
150GB? I’m very surprised there is so much data in our
phab! That seems huge...
My guess is that this includes all the diffs for every revision
of every review (as well as all the
comments, etc), and it probably isn't as clever with diffs as
for example git. Which quite soon adds up
to huge numbers when you have tens of thousands of reviews.
Purse speculation of course, I have never looked inside
phabricator (or for that matter, any other
code-review tool).
--
Mats
—
Mehdi
Sadly, the progress bar isn't giving useful information
(plus I am not a good system admin), so I
couldn't tell the ETA...
FYI: According to previous maintainer, it takes a couple of
hours for the last upgrade, so this
should be done within a few hours (hopefully!).
On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via
llvm-dev mailto:llvm-...@lists.llvm.org>> wrote:
Is there any ETA?
-Krzysztof
On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote:
> That was a bad estimation. Database upgrade is taking
time.
>
> On Thu, Sep 29, 2016 at 11:03 AM Eric Liu
mailto:ioe...@google.com>
> <mailto:ioe...@google.com
<mailto:ioe...@google.com>>> wrote:
>
> Hi all,
>
> Phabricator(reviews.llvm.org
<http://reviews.llvm.org/> <http://reviews.llvm.org
<http://reviews.llvm.org/>>) will be down
> for ~30 mins for an upgrade. Sorry for the short
notice.
>
> Regards,
> Eric
>
>
>
> _______
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
<mailto:llvm-...@lists.llvm.org>
>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
--
Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum,
hosted by The Linux Foundation
_______
LLVM Developers mailing list
llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______
LLVM Developers mailing list
llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)
Scope’s constructor passes the parameter ScopeFlags to Scope::Init, which calls setFlags(Scope *parent, unsigned flags) and setFlags initializes Scope::Flags to the value passed to the constructor. > On Apr 29, 2016, at 11:36 AM, Richard Smith wrote: > > On Fri, Apr 29, 2016 at 11:07 AM, Akira Hatanaka via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > If I add an assert to check (F != Flags) in setFlags, 2700+ out of 5000+ > clang regression tests fail. I haven’t figured out which parts of clang are > passing the same value to setFlags. > > What are you initializing Flags to in the constructor? >> On Apr 28, 2016, at 7:38 PM, Richard Smith via cfe-commits >> mailto:cfe-commits@lists.llvm.org>> wrote: >> >> On Thu, Apr 28, 2016 at 7:34 PM, Akira Hatanaka via cfe-commits >> mailto:cfe-commits@lists.llvm.org>> wrote: >> ahatanak added a comment. >> >> Thanks for the review. I committed the patch in r267956 and r267975. >> >> Do you think I should make setFlags(unsigned F) return early if F == Flags? >> >> I don't think that should happen in practice, so it doesn't seem worth >> checking. >> >> Repository: >> rL LLVM >> >> http://reviews.llvm.org/D19175 <http://reviews.llvm.org/D19175> >> >> >> >> _______ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits> > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits> > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Upgrading phabricator
> On Sep 29, 2016, at 11:04 PM, Eric Liu wrote: > > I've switched the default email format to be plain text only now. This option > should be per-user configurable, but somehow it is not shown in the > "Settings"; I'll try if I can make the option personalized. > > Regarding new features and bug fixes in this upgrade, I don't really have a > list since the Phabricator we are running is the open-source repo + some > local modification. The last merge was more than one year ago, so I guess > there should be a long list of new features and bug fixes. > > Some new features that I am aware of: > - Syntax highlighting. > - Patch size in email headers > - HTML email (disabled) > - More compatible with modern arc (the reason for this upgrade) > - and more to be discovered! :) > > @Mehdi Deleting unposted inline comments works for me. At which patch did > this issue occur? I picked randomly in the “All revisions” list. (For example: https://reviews.llvm.org/D25094 ) It seems I can delete comment unless I edited it first. Strange… — Mehdi > > - Eric > > On Fri, Sep 30, 2016 at 7:39 AM Mehdi Amini <mailto:mehdi.am...@apple.com>> wrote: > One of the new “feature” is that emails are HTML only right now. Not quite > nice for the archive (or for interacting by email). > See for instance: > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html > <http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html> > > (Also the funky "[Changed Subscribers] “ in the title) > > Another issue is that we can’t delete unposted inline comment anymore. > > — > Mehdi > >> On Sep 29, 2016, at 9:35 PM, Zachary Turner via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> >> You mentioned this was for an upgrade. Are there any major new features or >> bugfixes to be aware of? >> On Thu, Sep 29, 2016 at 9:26 PM Eric Liu via llvm-commits >> mailto:llvm-comm...@lists.llvm.org>> wrote: >> Hi all, >> >> Phabricator is (finally) back online! Let me know if you have any feedback >> or problem :) >> >> Thanks, >> Eric >> >> On Thu, Sep 29, 2016 at 10:23 PM Eric Liu > <mailto:ioe...@google.com>> wrote: >> According to top and iotop, mysqld is still working, and the progress bar >> did move by a little bit, so I think it's just really slow. Apologies if >> this is blocking you. >> >> On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> Still no word on when it will be back up? It's not hung is it? :D >> >> On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> >>> On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev >> <mailto:llvm-...@lists.llvm.org>> wrote: >>> >>> Sorry for blocking everyone for so long. >> >> No pb, thanks very much for taking care of it :) >> >>> It has been more than a year since the last upgrade, and mysql is adjusting >>> schema for a table with ~150G data on a single VM instance. >> >> 150GB? I’m very surprised there is so much data in our phab! That seems >> huge... >> >> My guess is that this includes all the diffs for every revision of every >> review (as well as all the comments, etc), and it probably isn't as clever >> with diffs as for example git. Which quite soon adds up to huge numbers when >> you have tens of thousands of reviews. >> >> Purse speculation of course, I have never looked inside phabricator (or for >> that matter, any other code-review tool). >> >> -- >> Mats >> >> — >> Mehdi >> >>> Sadly, the progress bar isn't giving useful information (plus I am not a >>> good system admin), so I couldn't tell the ETA... >>> >>> FYI: According to previous maintainer, it takes a couple of hours for the >>> last upgrade, so this should be done within a few hours (hopefully!). >>> >>> On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via llvm-dev >>> mailto:llvm-...@lists.llvm.org>> wrote: >>> Is there any ETA? >>> >>> -Krzysztof >>> >>> On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote: >>> > That was a bad estimation. Database upgrade is taking time. >>> > >>> > On T
Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)
OK, I understand your question now.
I added the assert to the public overload of setFlags that has one parameter
(just the flag value), not the one the constructor eventually calls.
void setFlags(unsigned F) { assert(F != Flags); setFlags(getParent(), F); }
> On Apr 29, 2016, at 12:13 PM, Richard Smith wrote:
>
> On Fri, Apr 29, 2016 at 12:12 PM, Akira Hatanaka via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Scope’s constructor passes the parameter ScopeFlags to Scope::Init, which
> calls setFlags(Scope *parent, unsigned flags) and setFlags initializes
> Scope::Flags to the value passed to the constructor.
>
> Right, but you're making setFlags assert (F != Flags), at which point Flags
> is presumably uninitialized if the constructor didn't set it itself.
>
>> On Apr 29, 2016, at 11:36 AM, Richard Smith > <mailto:rich...@metafoo.co.uk>> wrote:
>>
>> On Fri, Apr 29, 2016 at 11:07 AM, Akira Hatanaka via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> If I add an assert to check (F != Flags) in setFlags, 2700+ out of 5000+
>> clang regression tests fail. I haven’t figured out which parts of clang are
>> passing the same value to setFlags.
>>
>> What are you initializing Flags to in the constructor?
>>> On Apr 28, 2016, at 7:38 PM, Richard Smith via cfe-commits
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>>
>>> On Thu, Apr 28, 2016 at 7:34 PM, Akira Hatanaka via cfe-commits
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>> ahatanak added a comment.
>>>
>>> Thanks for the review. I committed the patch in r267956 and r267975.
>>>
>>> Do you think I should make setFlags(unsigned F) return early if F == Flags?
>>>
>>> I don't think that should happen in practice, so it doesn't seem worth
>>> checking.
>>>
>>> Repository:
>>> rL LLVM
>>>
>>> http://reviews.llvm.org/D19175 <http://reviews.llvm.org/D19175>
>>>
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>>>
>>> _______
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>>
>>
>> _______
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>>
>>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [cfe-dev] [llvm-dev] Upgrading phabricator
Hi Eric, Thanks for your work. > On Sep 29, 2016, at 11:04 PM, Eric Liu via cfe-dev > wrote: > > I've switched the default email format to be plain text only now. This option > should be per-user configurable, but somehow it is not shown in the > "Settings"; I'll try if I can make the option personalized. > > Regarding new features and bug fixes in this upgrade, I don't really have a > list since the Phabricator we are running is the open-source repo + some > local modification. The last merge was more than one year ago, so I guess > there should be a long list of new features and bug fixes. > > Some new features that I am aware of: > - Syntax highlighting. > - Patch size in email headers > - HTML email (disabled) > - More compatible with modern arc (the reason for this upgrade) Can you please elaborate? Is this meant for bug-fixing only, or can we use some new features from arc? Adam > - and more to be discovered! :) > > @Mehdi Deleting unposted inline comments works for me. At which patch did > this issue occur? > > - Eric > > On Fri, Sep 30, 2016 at 7:39 AM Mehdi Amini <mailto:mehdi.am...@apple.com>> wrote: > One of the new “feature” is that emails are HTML only right now. Not quite > nice for the archive (or for interacting by email). > See for instance: > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html > <http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html> > > (Also the funky "[Changed Subscribers] “ in the title) > > Another issue is that we can’t delete unposted inline comment anymore. > > — > Mehdi > >> On Sep 29, 2016, at 9:35 PM, Zachary Turner via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> >> You mentioned this was for an upgrade. Are there any major new features or >> bugfixes to be aware of? >> On Thu, Sep 29, 2016 at 9:26 PM Eric Liu via llvm-commits >> mailto:llvm-comm...@lists.llvm.org>> wrote: >> Hi all, >> >> Phabricator is (finally) back online! Let me know if you have any feedback >> or problem :) >> >> Thanks, >> Eric >> >> On Thu, Sep 29, 2016 at 10:23 PM Eric Liu > <mailto:ioe...@google.com>> wrote: >> According to top and iotop, mysqld is still working, and the progress bar >> did move by a little bit, so I think it's just really slow. Apologies if >> this is blocking you. >> >> On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> Still no word on when it will be back up? It's not hung is it? :D >> >> On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> >>> On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev >> <mailto:llvm-...@lists.llvm.org>> wrote: >>> >>> Sorry for blocking everyone for so long. >> >> No pb, thanks very much for taking care of it :) >> >>> It has been more than a year since the last upgrade, and mysql is adjusting >>> schema for a table with ~150G data on a single VM instance. >> >> 150GB? I’m very surprised there is so much data in our phab! That seems >> huge... >> >> My guess is that this includes all the diffs for every revision of every >> review (as well as all the comments, etc), and it probably isn't as clever >> with diffs as for example git. Which quite soon adds up to huge numbers when >> you have tens of thousands of reviews. >> >> Purse speculation of course, I have never looked inside phabricator (or for >> that matter, any other code-review tool). >> >> -- >> Mats >> >> — >> Mehdi >> >>> Sadly, the progress bar isn't giving useful information (plus I am not a >>> good system admin), so I couldn't tell the ETA... >>> >>> FYI: According to previous maintainer, it takes a couple of hours for the >>> last upgrade, so this should be done within a few hours (hopefully!). >>> >>> On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via llvm-dev >>> mailto:llvm-...@lists.llvm.org>> wrote: >>> Is there any ETA? >>> >>> -Krzysztof >>> >>> On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote: >>> > That was a bad estimation. Database upgrade is taking time. >>> > >>> > On Thu, Sep 29, 201
Re: [lldb-dev] [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3
NetBSD is ready (cmake-3.5.2). It now runs 7.0 kernel, 7.99.29 userland and newer GNU toolchain (GCC 5.3, LD 2.26). http://lab.llvm.org:8011/buildslaves/lldb-amd64-ninja-netbsd7 On 26.05.2016 18:57, Zachary Turner via lldb-dev wrote: > Windows LLDB is done > > On Thu, May 26, 2016 at 2:39 AM Daniel Sanders via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > > All the MIPS buildbots are ready too. > > __ __ > > *From:*llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org > <mailto:llvm-dev-boun...@lists.llvm.org>] *On Behalf Of *NAKAMURA > Takumi via llvm-dev > *Sent:* 25 May 2016 23:03 > *To:* Chris Bieneman; llvm-...@lists.llvm.org > <mailto:llvm-...@lists.llvm.org>; cfe-...@lists.llvm.org > <mailto:cfe-...@lists.llvm.org>; lldb-dev@lists.llvm.org > <mailto:lldb-dev@lists.llvm.org> > *Subject:* Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum > version to 3.4.3 > > __ __ > > I am ready, regarding to, http://bb.pgr.jp/ > > On Wed, May 25, 2016 at 5:54 AM Chris Bieneman <mailto:be...@apple.com>> wrote: > > Meant to send this yesterday, but I want to remind everyone that > we’re going to be raising the CMake minimum version to 3.4.3 > next week. > > If you maintain bots please ensure that your bots are updated by > end of day 5/29 so that we can move on 5/30 (next Monday). > > I have already heard from most bot owners either saying they had > made the change, or scheduled to make it. > > If you have any questions or concerns please let me know. > > Thank you, > -Chris > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [Release-testers] 13.0.0-rc3 has been tagged
On 20/09/2021 19:53, Brian Cain wrote:
Is there a way to set some kind of variable to
limit the concurrency for building (only) these targets? Like
LLVM_PARALLEL_LINK_JOBS works today.
AFAIK, that's not possible ATM. I agree that it would be a good
workaround and we should look into this. But it will be tricky to get
this in on time for Release 13.
I suspect that you are already using either ld.gold or lld? Perhaps you
could build all of LLVM with LLVM_PARALLEL_COMPILE_JOBS=1 (or some other
small value)?
-Andrzej
What if test-release.sh defined
LLVM_PARALLEL_FLANG_COMPILE_JOBS to "1" (or I defined it in
-configure-flags) and there were some cmake magic that handled that
input to control how the build were invoked? I think that would be a
good workaround.
Thanks,
-Andrzej
>
> $ cat
clang+llvm-13.0.0-rc3-x86_64-linux-gnu-ubuntu-20.04.tar.xz.sha256
> 488ff13c9a54f6b7b2aeb26e930da7d72e32a15542929cd642fc0b7d37e79967
> clang+llvm-13.0.0-rc3-x86_64-linux-gnu-ubuntu-20.04.tar.xz
>
> On Mon, Sep 13, 2021 at 11:40 PM Tom Stellard via Release-testers
> mailto:release-test...@lists.llvm.org>
<mailto:release-test...@lists.llvm.org
<mailto:release-test...@lists.llvm.org>>>
> wrote:
>
> Hi,
>
> I've tagged 13.0.0-rc3. This will likely be the last rc unless
> there are
> critical bugs that are found. Please test the release and report
> results.
>
> -Tom
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
<mailto:release-test...@lists.llvm.org>
<mailto:release-test...@lists.llvm.org
<mailto:release-test...@lists.llvm.org>>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
<https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers>
>
<https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
<https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers>>
>
>
>
> --
> -Brian
>
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org <mailto:openmp-...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev>
>
--
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged
On 01/09/2019 05:03 AM, Brian Cain wrote: > > > On Tue, Jan 8, 2019 at 11:25 PM Tom Stellard <mailto:tstel...@redhat.com>> wrote: > > On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote: > > Can the ubuntu tarballs be published to the download site? They're not > available yet. > > > > These are up on the download site now. > > > Tom, releases.llvm.org <http://releases.llvm.org> only shows Windows and > FreeBSD tarballs for 7.0.1 from what I can see. > I forgot to add the links, they are up now. > Also, the front page of https://releases.llvm.org/ needs a new entry for > 7.0.1 in the table under "Download". > This has been fixed too. -Tom > > > > On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev > mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: > > > > Ubuntu and SLES tarballs uploaded. I haven't had a chance to make > a SLES12 build yet, but I will try in the coming days. > > > > f7553a0d66092ca0bbe1eab2af405523a18bafba > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz > > 41db01a3b216df4fc22fae9c44e248889f9a01ed > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz > > caf149635742622a3a5b220146ff34f9202b8670 > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz > > 5e2b33ac129b8471683dccaeb2818004eb5acea8 > clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz > > > > > > On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers > mailto:release-test...@lists.llvm.org> > <mailto:release-test...@lists.llvm.org > <mailto:release-test...@lists.llvm.org>>> wrote: > > > > On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers > mailto:release-test...@lists.llvm.org> > <mailto:release-test...@lists.llvm.org > <mailto:release-test...@lists.llvm.org>>> wrote: > > > > > > I've tagged the 7.0.1 final release. Testers may begin > uploading binaries. > > > > Main test results on amd64-freebsd11 had 1 more Expected Pass > compared to 7.0.1 rc3, and no more Passes With Retry: > > > > Expected Passes: 52445(7.0.1 rc3: 52444) > > Passes With Retry : n/a(7.0.1 rc3: 1) > > Expected Failures : 232(7.0.1 rc3: 232) > > Unsupported Tests : 3687(7.0.1 rc3: 3687) > > Unexpected Passes : 1(7.0.1 rc3: 1) > > Unexpected Failures: 491(7.0.1 rc3: 491) > > > > Test-suite results on amd64-freebsd11 did not change: > > > > Expected Passes: 903(7.0.1 rc3: 903) > > Unexpected Failures: 3(7.0.1 rc3: 3) > > > > Test results on i386-freebsd11 had 1 more Expected Pass > compared to 7.0.1 rc3, and 3 less Unexpected Failures: > > > > Expected Passes: 50254(7.0.1 rc3: 50253) > > Passes With Retry : 2(7.0.1 rc3: n/a) > > Expected Failures : 226(7.0.1 rc3: 226) > > Unsupported Tests : 2502(7.0.1 rc3: 2502) > > Unexpected Failures: 272(7.0.1 rc3: 275) > > > > The test-suite still doesn't build on i386-freebsd11, but that > is a known issue. > > > > I have uploaded: > > > > SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = > 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407 > > SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = > 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36 > > > > -Dimitry > > > > _______ > > Release-testers mailing list > > release-test...@lists.llvm.org > <mailto:release-test...@lists.llvm.org> > <mailto:release-test...@lists.llvm.org > <mailto:release-test...@lists.llvm.org>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > > > > > -- > > -Brian > > ___ > > cfe-dev mailing list > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > ___ > > Release-testers mailing list > > release-test...@lists.llvm.org <mailto:release-test...@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > > > -- > -Brian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] December LLVM bay-area social is this Thursday!
In case Steins doesn't work out.. BJs in Cupertino has a large space for groups but that would mean closer to Cupertino area. -Tanya > On Dec 28, 2019, at 8:50 PM, Eric Christopher via llvm-dev > wrote: > > Still a bit of a Twitter thread too. A few more options maybe if we want to > move to downtown San Jose. > > On Sat, Dec 28, 2019, 8:47 PM Chandler Carruth via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > +1, i'm just glad you're making progress on a promising option! > > On Sat, Dec 28, 2019 at 8:33 PM JF Bastien <mailto:jfbast...@apple.com>> wrote: > The guy on the phone said that wouldn’t be a problem 🤷♂️ > I hope that stays correct! Ideally we’d have the same deal: indeterminate > number of people, ordering off the menu. I’ll check with you if that’s not > the case. > > >> On Dec 28, 2019, at 7:41 PM, Chandler Carruth > <mailto:chandl...@google.com>> wrote: >> >> >> Mostly worried because we talked to them before and they wanted us to buy a >> banquet menu at A lot of dollars. >> >> On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev > <mailto:cfe-...@lists.llvm.org>> wrote: >> I reached out to Steins (which is right across the street) to see if they >> can host us. I’ll keep y’all posted, it seemed optimistic in our phone chat. >> >> >>> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev >>> mailto:cfe-...@lists.llvm.org>> wrote: >>> >>> Oof. :( >>> >>> Offhand, I can’t think of any place in particular. As one might imagine, >>> accommodating 50+ people isn’t always super easy for places to do. >>> >>> Suggestions welcome! >>> >>> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva >> <mailto:chisophu...@gmail.com>> wrote: >>> It looks like Tied House will be shutting down :( Do we have a replacement >>> venue? >>> >>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits >>> >>> <https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits> >>> >>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev >>> mailto:llvm-...@lists.llvm.org>> wrote: >>> We'll be at Tied House as usual, starting on Thursday the 5th at 7pm! >>> >>> If you can, help us plan and RSVP here: >>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb >>> <https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb> >>> >>> See everyone there! >>> _______ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >>> ___ >>> cfe-dev mailing list >>> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev> >> _______ >> cfe-dev mailing list >> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev> > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ 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] Attn Buildbot Owners: Would you like your builder to test the release branch?
Ping! Tom, any update on this? On Mon, 15 Feb 2021 at 20:02, Nemanja Ivanovic wrote: > We are interested in doing this for PPC as well. Not likely for all of our > bots, but one or two select ones. > > On Fri, Feb 12, 2021 at 11:51 AM Tom Stellard via cfe-dev < > cfe-...@lists.llvm.org> wrote: > >> On 2/12/21 1:49 AM, Omair Javaid wrote: >> > Hi Tom, >> > >> > We at Linaro are maintaining LLVM Arm/AArch64 buildbots and want a host >> buildbot for testing of release branches. >> > >> >> OK, that's great. >> >> > Kindly share the steps to do this. Do we have to host separate builbots >> for tracking release branches or is it possible to track multiple >> branches by existing buildbots assuming traffic on release branches is less >> frequent? >> > >> >> I've submitted a patch[1] to add the infrastructure for enabling builders >> on the release branch. Once this patch or something similar gets applied >> then we can start enabling individual builders. I'll follow up with you >> once this patch lands. >> >> -Tom >> >> >> [1] https://reviews.llvm.org/D96046 >> >> > On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev < >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote: >> > >> > On 2/2/21 1:23 AM, Diana Picus wrote: >> > > Hi Tom, >> > > >> > > This sounds interesting! Would this also make it possible to >> automatically get the release binaries from the buildbots, as opposed to >> manually uploading to the FTP server? >> > > >> > >> > Yes, this is something I would like to do. I think you could >> pretty easily run >> > the test-release.sh script on the bot. The only issue is finding a >> way to >> > securely upload the binaries. >> > >> > -Tom >> > >> > > Cheers, >> > > Diana >> > > >> > > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev < >> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: >> > > >> > > Hi, >> > > >> > > I would like to improve the testing coverage in the release >> branch, so if you >> > > are a buildbot owner and would like to enable your builder >> for the release branch, >> > > let me know, and I can help get it enabled. >> > > >> > > Also, if you have any ideas for some more extensive testing >> that might be too >> > > slow to run on the main branch, we may be able to enable it >> on the release >> > > branch either running once per commit or once per tag. >> > > >> > > Thanks, >> > > Tom >> > > >> > > ___ >> > > cfe-dev mailing list >> > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> >> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev < >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev> >> > > >> > >> > ___ >> > LLVM Developers mailing list >> > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev < >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> > >> > >> > >> > -- >> > Omair Javaid >> > www.linaro.org <http://www.linaro.org> >> >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > -- Omair Javaid www.linaro.org ___ 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] December LLVM bay-area social is this Thursday!
Yep! On Tue, Dec 31, 2019 at 5:53 PM George Burgess IV via cfe-dev < cfe-...@lists.llvm.org> wrote: > Thank you all! > > To clarify, a booking with Steins has already been made, yeah? > > George > > On Mon, Dec 30, 2019 at 10:28 AM Tanya Lattner via cfe-dev < > cfe-...@lists.llvm.org> wrote: > >> In case Steins doesn't work out.. BJs in Cupertino has a large space for >> groups but that would mean closer to Cupertino area. >> >> -Tanya >> >> On Dec 28, 2019, at 8:50 PM, Eric Christopher via llvm-dev < >> llvm-...@lists.llvm.org> wrote: >> >> Still a bit of a Twitter thread too. A few more options maybe if we want >> to move to downtown San Jose. >> >> On Sat, Dec 28, 2019, 8:47 PM Chandler Carruth via llvm-dev < >> llvm-...@lists.llvm.org> wrote: >> >>> +1, i'm just glad you're making progress on a promising option! >>> >>> On Sat, Dec 28, 2019 at 8:33 PM JF Bastien wrote: >>> >>>> The guy on the phone said that wouldn’t be a problem 🤷♂️ >>>> I hope that stays correct! Ideally we’d have the same deal: >>>> indeterminate number of people, ordering off the menu. I’ll check with you >>>> if that’s not the case. >>>> >>>> >>>> On Dec 28, 2019, at 7:41 PM, Chandler Carruth >>>> wrote: >>>> >>>> >>>> Mostly worried because we talked to them before and they wanted us to >>>> buy a banquet menu at A lot of dollars. >>>> >>>> On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev < >>>> cfe-...@lists.llvm.org> wrote: >>>> >>>>> I reached out to Steins (which is right across the street) to see if >>>>> they can host us. I’ll keep y’all posted, it seemed optimistic in our >>>>> phone >>>>> chat. >>>>> >>>>> >>>>> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev < >>>>> cfe-...@lists.llvm.org> wrote: >>>>> >>>>> Oof. :( >>>>> >>>>> Offhand, I can’t think of any place in particular. As one might >>>>> imagine, accommodating 50+ people isn’t always super easy for places to >>>>> do. >>>>> >>>>> Suggestions welcome! >>>>> >>>>> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva >>>>> wrote: >>>>> >>>>>> It looks like Tied House will be shutting down :( Do we have a >>>>>> replacement venue? >>>>>> >>>>>> >>>>>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits >>>>>> >>>>>> >>>>>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev < >>>>>> llvm-...@lists.llvm.org> wrote: >>>>>> >>>>>>> We'll be at Tied House as usual, starting on Thursday the 5th at 7pm! >>>>>>> >>>>>>> If you can, help us plan and RSVP here: >>>>>>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb >>>>>>> >>>>>>> See everyone there! >>>>>>> >>>>>> ___ >>>>>>> LLVM Developers mailing list >>>>>>> llvm-...@lists.llvm.org >>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>> >>>>>> ___ >>>>> cfe-dev mailing list >>>>> cfe-...@lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>>> >>>>> >>>>> ___ >>>>> cfe-dev mailing list >>>>> cfe-...@lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>>> >>>> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ 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] December LLVM bay-area social is this Thursday!
Woo hoo :) On Tue, Dec 31, 2019 at 6:06 PM Eric Christopher wrote: > Yep! > > On Tue, Dec 31, 2019 at 5:53 PM George Burgess IV via cfe-dev < > cfe-...@lists.llvm.org> wrote: > >> Thank you all! >> >> To clarify, a booking with Steins has already been made, yeah? >> >> George >> >> On Mon, Dec 30, 2019 at 10:28 AM Tanya Lattner via cfe-dev < >> cfe-...@lists.llvm.org> wrote: >> >>> In case Steins doesn't work out.. BJs in Cupertino has a large space for >>> groups but that would mean closer to Cupertino area. >>> >>> -Tanya >>> >>> On Dec 28, 2019, at 8:50 PM, Eric Christopher via llvm-dev < >>> llvm-...@lists.llvm.org> wrote: >>> >>> Still a bit of a Twitter thread too. A few more options maybe if we want >>> to move to downtown San Jose. >>> >>> On Sat, Dec 28, 2019, 8:47 PM Chandler Carruth via llvm-dev < >>> llvm-...@lists.llvm.org> wrote: >>> >>>> +1, i'm just glad you're making progress on a promising option! >>>> >>>> On Sat, Dec 28, 2019 at 8:33 PM JF Bastien wrote: >>>> >>>>> The guy on the phone said that wouldn’t be a problem 🤷♂️ >>>>> I hope that stays correct! Ideally we’d have the same deal: >>>>> indeterminate number of people, ordering off the menu. I’ll check with you >>>>> if that’s not the case. >>>>> >>>>> >>>>> On Dec 28, 2019, at 7:41 PM, Chandler Carruth >>>>> wrote: >>>>> >>>>> >>>>> Mostly worried because we talked to them before and they wanted us to >>>>> buy a banquet menu at A lot of dollars. >>>>> >>>>> On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev < >>>>> cfe-...@lists.llvm.org> wrote: >>>>> >>>>>> I reached out to Steins (which is right across the street) to see if >>>>>> they can host us. I’ll keep y’all posted, it seemed optimistic in our >>>>>> phone >>>>>> chat. >>>>>> >>>>>> >>>>>> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev < >>>>>> cfe-...@lists.llvm.org> wrote: >>>>>> >>>>>> Oof. :( >>>>>> >>>>>> Offhand, I can’t think of any place in particular. As one might >>>>>> imagine, accommodating 50+ people isn’t always super easy for places to >>>>>> do. >>>>>> >>>>>> Suggestions welcome! >>>>>> >>>>>> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva >>>>>> wrote: >>>>>> >>>>>>> It looks like Tied House will be shutting down :( Do we have a >>>>>>> replacement venue? >>>>>>> >>>>>>> >>>>>>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits >>>>>>> >>>>>>> >>>>>>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev < >>>>>>> llvm-...@lists.llvm.org> wrote: >>>>>>> >>>>>>>> We'll be at Tied House as usual, starting on Thursday the 5th at >>>>>>>> 7pm! >>>>>>>> >>>>>>>> If you can, help us plan and RSVP here: >>>>>>>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb >>>>>>>> >>>>>>>> See everyone there! >>>>>>>> >>>>>>> _______ >>>>>>>> LLVM Developers mailing list >>>>>>>> llvm-...@lists.llvm.org >>>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>>> >>>>>>> ___ >>>>>> cfe-dev mailing list >>>>>> cfe-...@lists.llvm.org >>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>>>> >>>>>> >>>>>> ___ >>>>>> cfe-dev mailing list >>>>>> cfe-...@lists.llvm.org >>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>>>> >>>>> ___ >>>> LLVM Developers mailing list >>>> llvm-...@lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> ___ >>> cfe-dev mailing list >>> cfe-...@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[llvm-bugs] [Bug 40955] New: lists.llvm.org accepts passwords and is not requiring an SSL connection.
https://bugs.llvm.org/show_bug.cgi?id=40955 Bug ID: 40955 Summary: lists.llvm.org accepts passwords and is not requiring an SSL connection. Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: m...@sqlby.me CC: llvm-bugs@lists.llvm.org, m...@sqlby.me Inital report from Jonny Grant: This page accepts passwords without being on a secure connection. Can llvm buy the SSL certificate and simply redirect from http? http://lists.llvm.org/cgi-bin/mailman/options/cfe-dev Interestingly. There does seem to be an SSL certificate on the server: https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev the problem is that: 1. The http server doesn't refresh to https 2. the main clang page links to http https://clang.llvm.org/get_involved.html 3. the mailmain https page even links back to plain http archive! http://lists.llvm.org/pipermail/cfe-dev/ 4. Even entering https://lists.llvm.org/ HTTPS redirects back to http://lists.llvm.org/mailman/listinfo ! Fix is pretty easy, take mailman off http server http://lists.llvm.org/ and put a 302 redirect back to https://lists.llvm.org/ Cheers, Jonny -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
Re: [lldb-dev] RFC: Break/Watchpoint refactor
Why? The macro states the intent explicitly, rather than having to deduce it from details scattered through the class definition. Jim > On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev > wrote: > > Doing it everywhere would be a public service IMO. I don't like macros > either. > > Sean > >> On Sep 27, 2016, at 3:07 PM, Zachary Turner via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> FWIW LLVM removed all it's disallow copy / assign macros in favor of >> explicitly writing it. I agree it's easier to just change the macro, but I >> would just do what LLVM does as long as you don't mind the extra work. >> >> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> >> On 09/27/2016 03:37 PM, Enrico Granata wrote: >>> >>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev >>>> mailto:lldb-dev@lists.llvm.org>> wrote: >>>> >>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro >>>> DISALLOW_COPY_AND_ASSIGN >>> >>> >>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That >>> seems like a trivial change.. >> >> That was my first thought as well. Still, I personally try to avoid macros. >> On the other hand that one is simple enough that it may be justified. >> >>> >>> Thanks, >>> - Enrico >>> 📩 egranata@.com ☎️ 27683 >>> >> >> _______ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC: Break/Watchpoint refactor
The issue I have with the DISALLOW_ macro is that when you're looking to see what sort of constructors etc. are possible, you now have to look through a macro. Personally, I like to see what constructors are available on an object in one list, and not have to guess about whether e.g. a move constructor is present or disallowed. Sean > On Sep 27, 2016, at 3:24 PM, Jim Ingham wrote: > > Why? The macro states the intent explicitly, rather than having to deduce it > from details scattered through the class definition. > > Jim > >> On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Doing it everywhere would be a public service IMO. I don't like macros >> either. >> >> Sean >> >>> On Sep 27, 2016, at 3:07 PM, Zachary Turner via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> FWIW LLVM removed all it's disallow copy / assign macros in favor of >>> explicitly writing it. I agree it's easier to just change the macro, but I >>> would just do what LLVM does as long as you don't mind the extra work. >>> >>> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> >>> On 09/27/2016 03:37 PM, Enrico Granata wrote: >>>> >>>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev >>>>> mailto:lldb-dev@lists.llvm.org>> wrote: >>>>> >>>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro >>>>> DISALLOW_COPY_AND_ASSIGN >>>> >>>> >>>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That >>>> seems like a trivial change.. >>> >>> That was my first thought as well. Still, I personally try to avoid >>> macros. On the other hand that one is simple enough that it may be >>> justified. >>> >>>> >>>> Thanks, >>>> - Enrico >>>> 📩 egranata@.com ☎️ 27683 >>>> >>> >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [llvm-dev] Upgrading phabricator
You mentioned this was for an upgrade. Are there any major new features or bugfixes to be aware of? On Thu, Sep 29, 2016 at 9:26 PM Eric Liu via llvm-commits < llvm-comm...@lists.llvm.org> wrote: > Hi all, > > Phabricator is (finally) back online! Let me know if you have any feedback > or problem :) > > Thanks, > Eric > > On Thu, Sep 29, 2016 at 10:23 PM Eric Liu wrote: > > According to top and iotop, mysqld is still working, and the progress bar > did move by a little bit, so I think it's just really slow. Apologies if > this is blocking you. > > On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Still no word on when it will be back up? It's not hung is it? :D > > On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > > On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Sorry for blocking everyone for so long. > > > No pb, thanks very much for taking care of it :) > > It has been more than a year since the last upgrade, and mysql is > adjusting schema for a table with ~150G data on a single VM instance. > > > 150GB? I’m very surprised there is so much data in our phab! That seems > huge... > > > My guess is that this includes all the diffs for every revision of every > review (as well as all the comments, etc), and it probably isn't as clever > with diffs as for example git. Which quite soon adds up to huge numbers > when you have tens of thousands of reviews. > > Purse speculation of course, I have never looked inside phabricator (or > for that matter, any other code-review tool). > > -- > Mats > > > — > Mehdi > > Sadly, the progress bar isn't giving useful information (plus I am not a > good system admin), so I couldn't tell the ETA... > > FYI: According to previous maintainer, it takes a couple of hours for the > last upgrade, so this should be done within a few hours (hopefully!). > > On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Is there any ETA? > > -Krzysztof > > On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote: > > That was a bad estimation. Database upgrade is taking time. > > > > On Thu, Sep 29, 2016 at 11:03 AM Eric Liu > <mailto:ioe...@google.com>> wrote: > > > > Hi all, > > > > Phabricator(reviews.llvm.org <http://reviews.llvm.org>) will be down > > for ~30 mins for an upgrade. Sorry for the short notice. > > > > Regards, > > Eric > > > > > > > > _______ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > ___________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > llvm-commits mailing list > llvm-comm...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
Likewise. The clearly stated intended consequences are well worth promoting, and any unintended consequences can be addressed with good judgement and ongoing revision. Thank you for your efforts to make sure LLVM remains friendly and inclusive. Kate Stone k8st...@apple.com <mailto:k8st...@apple.com> Xcode Low Level Tools > On Jun 30, 2016, at 1:18 PM, Jim Grosbach via lldb-dev > wrote: > > Thanks, Chandler, for all your work on this. I’m glad to see this moving > forward. > > -Jim > >> On Jun 30, 2016, at 11:55 AM, Chandler Carruth via llvm-dev >> mailto:llvm-...@lists.llvm.org>> wrote: >> >> Hello folks, >> >> As mentioned some time ago[1], we’ve had a long (looong) series of >> discussions about establishing a code-of-conduct for the LLVM project as a >> whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 >> <http://reviews.llvm.org/D13741> code review. >> >> The discussion has largely died down for some time, and towards the end >> there has been pretty wide support for the draft wording we have now. It >> isn’t perfect, and there are still some important questions around forming >> the advisory committee to handle reporting, but I think the wording is at a >> good point of compromise in a challenging area. >> >> Based on the support, I’m going to land the patch that adds the draft. I’m >> hoping this will immediately provide good advice and guidance, and I’m >> hoping to see motion on setting up a reasonable advisory committee and >> resolving any issues around reporting so we can make this an official part >> of the community. >> >> I sending this as a heads up so folks are aware, not to start a new >> discussion thread. There are existing discussion threads[2] on llvm-dev if >> folks want to join in active discussion or we can start fresh ones, but I >> would encourage people to carefully read the discussion that has already >> taken place to avoid revisiting areas that have already been heavily >> discussed. >> >> Also, many thanks to the folks who provided all their opinions on the >> mailing list threads and in person in long discussions about this topic. >> >> Thanks, >> -Chandler >> >> [1]: Prior announcements: >> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html >> <http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html> >> http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html >> <http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html> >> http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html >> <http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html> >> http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html >> <http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html> >> >> [2]: Existing threads: >> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html >> <http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html> >> http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html >> <http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html> >> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html >> >> <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html>___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: r365030 - Make a buildbot using a buggy gcc happy
Thanks Richard!
> On Jul 8, 2019, at 12:46 PM, Richard Smith via cfe-commits
> wrote:
>
> Committed as r365377.
>
> On Mon, 8 Jul 2019 at 12:43, Kristóf Umann via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Thank you so much! Sorry for the inconvencience, I'll be that much more
> careful next time :)
>
> =) No worries. It's one of those pesky "no diagnostic required" cases;
> they're often a pain.
>
> On Mon, 8 Jul 2019, 21:42 Richard Smith, <mailto:rich...@metafoo.co.uk>> wrote:
> I'll commit the change below once my testing finishes :)
>
> On Mon, 8 Jul 2019 at 12:40, Kristóf Umann via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Noted, thanks! Gabor, could you please fix this?
>
> On Mon, 8 Jul 2019, 21:37 Richard Smith, <mailto:rich...@metafoo.co.uk>> wrote:
> This is in any case the wrong fix. The code *is* wrong, for the reason this
> compiler is reporting.
>
> The correct fix is to declare the explicit specializations in the header file:
>
> template <> void CFGDominatorTreeImpl::anchor();
> template <> void CFGDominatorTreeImpl::anchor();
>
> Clang will tell you to do this under -Wundefined-func-template (which we
> haven't turned on by default because people get this wrong too often...).
>
> On Mon, 8 Jul 2019 at 12:29, JF Bastien via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Kristof,
>
> It looks like your fix didn’t address all the bots:
>
> /Users/buildslave/jenkins/workspace/clang-stage2-coverage-R/llvm/tools/clang/lib/Analysis/Dominators.cpp:14:48:
> error: explicit specialization of 'anchor' after instantiation
> void CFGDominatorTreeImpl::anchor() {}
>^
> /Users/buildslave/jenkins/workspace/clang-stage2-coverage-R/llvm/tools/clang/include/clang/Analysis/Analyses/Dominators.h:225:3:
> note: implicit instantiation first required here
> ControlDependencyCalculator(CFG *cfg)
> ^
>
> Can you please address the issue?
> http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/4153/consoleFull
> <http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/4153/consoleFull>
>
> Thanks,
>
> JF
>
>
>> On Jul 3, 2019, at 5:06 AM, Kristof Umann via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>
>> Author: szelethus
>> Date: Wed Jul 3 05:06:10 2019
>> New Revision: 365030
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=365030&view=rev
>> <http://llvm.org/viewvc/llvm-project?rev=365030&view=rev>
>> Log:
>> Make a buildbot using a buggy gcc happy
>>
>> When specializing a template in a namespace, it has to be in a namespace
>> block, else gcc will get confused. Hopefully this fixes the issue.
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480
>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480>
>>
>> Modified:
>>cfe/trunk/lib/Analysis/Dominators.cpp
>>
>> Modified: cfe/trunk/lib/Analysis/Dominators.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/Dominators.cpp?rev=365030&r1=365029&r2=365030&view=diff
>>
>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/Dominators.cpp?rev=365030&r1=365029&r2=365030&view=diff>
>> ==
>> --- cfe/trunk/lib/Analysis/Dominators.cpp (original)
>> +++ cfe/trunk/lib/Analysis/Dominators.cpp Wed Jul 3 05:06:10 2019
>> @@ -8,10 +8,12 @@
>>
>> #include "clang/Analysis/Analyses/Dominators.h"
>>
>> -using namespace clang;
>> +namespace clang {
>>
>> template <>
>> -void clang::CFGDominatorTreeImpl::anchor() {}
>> +void CFGDominatorTreeImpl::anchor() {}
>>
>> template <>
>> -void clang::CFGDominatorTreeImpl::anchor() {}
>> +void CFGDominatorTreeImpl::anchor() {}
>> +
>> +} // end of namespace clang
>>
>>
>> _______
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> <https://lists.ll
Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)
On Fri, Apr 29, 2016 at 12:12 PM, Akira Hatanaka via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Scope’s constructor passes the parameter ScopeFlags to Scope::Init, which > calls setFlags(Scope *parent, unsigned flags) and setFlags initializes > Scope::Flags to the value passed to the constructor. > Right, but you're making setFlags assert (F != Flags), at which point Flags is presumably uninitialized if the constructor didn't set it itself. > On Apr 29, 2016, at 11:36 AM, Richard Smith wrote: > > On Fri, Apr 29, 2016 at 11:07 AM, Akira Hatanaka via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> If I add an assert to check (F != Flags) in setFlags, 2700+ out of 5000+ >> clang regression tests fail. I haven’t figured out which parts of clang are >> passing the same value to setFlags. >> > > What are you initializing Flags to in the constructor? > >> On Apr 28, 2016, at 7:38 PM, Richard Smith via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >> On Thu, Apr 28, 2016 at 7:34 PM, Akira Hatanaka via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> ahatanak added a comment. >>> >>> Thanks for the review. I committed the patch in r267956 and r267975. >>> >>> Do you think I should make setFlags(unsigned F) return early if F == >>> Flags? >> >> >> I don't think that should happen in practice, so it doesn't seem worth >> checking. >> >> Repository: >>> rL LLVM >>> >>> http://reviews.llvm.org/D19175 >>> >>> >>> >>> ___ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> >> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> >> > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)
OK. Feel free to add an early exit if you like if F == Flags.
On Fri, Apr 29, 2016 at 12:19 PM, Akira Hatanaka via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> OK, I understand your question now.
>
> I added the assert to the public overload of setFlags that has one
> parameter (just the flag value), not the one the constructor eventually
> calls.
>
> void setFlags(unsigned F) { assert(F != Flags); setFlags(getParent(), F); }
>
> On Apr 29, 2016, at 12:13 PM, Richard Smith wrote:
>
> On Fri, Apr 29, 2016 at 12:12 PM, Akira Hatanaka via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Scope’s constructor passes the parameter ScopeFlags to Scope::Init, which
>> calls setFlags(Scope *parent, unsigned flags) and setFlags initializes
>> Scope::Flags to the value passed to the constructor.
>>
>
> Right, but you're making setFlags assert (F != Flags), at which point
> Flags is presumably uninitialized if the constructor didn't set it itself.
>
>
>> On Apr 29, 2016, at 11:36 AM, Richard Smith
>> wrote:
>>
>> On Fri, Apr 29, 2016 at 11:07 AM, Akira Hatanaka via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> If I add an assert to check (F != Flags) in setFlags, 2700+ out of 5000+
>>> clang regression tests fail. I haven’t figured out which parts of clang are
>>> passing the same value to setFlags.
>>>
>>
>> What are you initializing Flags to in the constructor?
>>
>>> On Apr 28, 2016, at 7:38 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>> On Thu, Apr 28, 2016 at 7:34 PM, Akira Hatanaka via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> ahatanak added a comment.
>>>>
>>>> Thanks for the review. I committed the patch in r267956 and r267975.
>>>>
>>>> Do you think I should make setFlags(unsigned F) return early if F ==
>>>> Flags?
>>>
>>>
>>> I don't think that should happen in practice, so it doesn't seem worth
>>> checking.
>>>
>>> Repository:
>>>> rL LLVM
>>>>
>>>> http://reviews.llvm.org/D19175
>>>>
>>>>
>>>>
>>>> _______
>>>> cfe-commits mailing list
>>>> cfe-commits@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>>
>>> _______
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] [cfe-dev] [llvm-dev] December LLVM bay-area social is this Thursday!
Thank you all! To clarify, a booking with Steins has already been made, yeah? George On Mon, Dec 30, 2019 at 10:28 AM Tanya Lattner via cfe-dev < cfe-...@lists.llvm.org> wrote: > In case Steins doesn't work out.. BJs in Cupertino has a large space for > groups but that would mean closer to Cupertino area. > > -Tanya > > On Dec 28, 2019, at 8:50 PM, Eric Christopher via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Still a bit of a Twitter thread too. A few more options maybe if we want > to move to downtown San Jose. > > On Sat, Dec 28, 2019, 8:47 PM Chandler Carruth via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> +1, i'm just glad you're making progress on a promising option! >> >> On Sat, Dec 28, 2019 at 8:33 PM JF Bastien wrote: >> >>> The guy on the phone said that wouldn’t be a problem 🤷♂️ >>> I hope that stays correct! Ideally we’d have the same deal: >>> indeterminate number of people, ordering off the menu. I’ll check with you >>> if that’s not the case. >>> >>> >>> On Dec 28, 2019, at 7:41 PM, Chandler Carruth >>> wrote: >>> >>> >>> Mostly worried because we talked to them before and they wanted us to >>> buy a banquet menu at A lot of dollars. >>> >>> On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev < >>> cfe-...@lists.llvm.org> wrote: >>> >>>> I reached out to Steins (which is right across the street) to see if >>>> they can host us. I’ll keep y’all posted, it seemed optimistic in our phone >>>> chat. >>>> >>>> >>>> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev < >>>> cfe-...@lists.llvm.org> wrote: >>>> >>>> Oof. :( >>>> >>>> Offhand, I can’t think of any place in particular. As one might >>>> imagine, accommodating 50+ people isn’t always super easy for places to do. >>>> >>>> Suggestions welcome! >>>> >>>> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva >>>> wrote: >>>> >>>>> It looks like Tied House will be shutting down :( Do we have a >>>>> replacement venue? >>>>> >>>>> >>>>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits >>>>> >>>>> >>>>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev < >>>>> llvm-...@lists.llvm.org> wrote: >>>>> >>>>>> We'll be at Tied House as usual, starting on Thursday the 5th at 7pm! >>>>>> >>>>>> If you can, help us plan and RSVP here: >>>>>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb >>>>>> >>>>>> See everyone there! >>>>>> >>>>> _______ >>>>>> LLVM Developers mailing list >>>>>> llvm-...@lists.llvm.org >>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> >>>>> ___ >>>> cfe-dev mailing list >>>> cfe-...@lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>> >>>> >>>> ___ >>>> cfe-dev mailing list >>>> cfe-...@lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>> >>> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ 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 [UPDATED]
Since Bugzilla numbers are all under 50,000 (at least for now:), can't we simply bump the GitHub issue/pull request numbers to 50,000, and start from there? Then it would be easy to identify: < 5 means Bugzilla, >= 5 means GitHub. Now somebody's only gotta find a way to file 5-200 bogus GitHub tickets. :) (Or ask GitHub support to bump the number synthetically.) -Dimitry > On 22 Apr 2020, at 09:10, James Henderson via cfe-dev > wrote: > > Similar to other people's experiences, I've worked on a common code base that > supported three different platforms, and each platform used a different > bugzilla with it's own numbering scheme. I regularly came across references > to "BZ123456" with no indication as to which of the three systems that > referred to. This would often mean having to go to each in turn and seeing if > the corresponding bug looked like it had anything to do with the related > topic. Fortunately, given that there were many other things using the same > bugzilla instances, this was usually pretty clear, but not always. Typos in > bug numbers sometimes made things even harder, since you had to spend three > times as long trying to guess. > > In other words +1 to using unique numbers, however we do it. > > On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev > mailto:cfe-...@lists.llvm.org>> wrote: > > On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote: > > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > >> mailto:cfe-...@lists.llvm.org> > >> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: > >> > >> +1 to James's take > >> > >> I'd prefer simplicity of implementation over perfection here. > >> > >> If we end up with two different bug numbering systems, that's a problem > >> that we will be paying for for many years. It's worth some investment now > >> to avoid that problem. And it doesn't seem like it really requires much > >> investment. > >> > >> Here's another path we could take: > >> > >> 1) Fork the llvm repository to a private "bugs" repository. Mirror the > >> bugzilla issues there. Iterate until we're happy, as per James's proposal. > >> 2) Sync the forked repository to the llvm repository, delete the llvm > >> repository, rename "bugs" to "llvm", and make it public. > >> > >> Then we'll have the first N bugs in llvm-project/llvm being *exactly* the > >> bugzilla bugs, and we'll have excised the existing github issues that we > >> want to pretend never existed anyway. > >> > >> > >> I think we've missed an important step in the planning here: we've not > >> agreed on a set of goals for the transition. Here are mine: > >> > >> * We end up with one single issue tracking system containing all issues, > >> both old and new, both open and closed. > >> * All links and references to existing bugs still work. > >> * We have a single bug numbering system covering all bugs, and old bugs > >> retain their numbers. > > Why are the bug numbers important? Could you help give some example use > > cases that require having > > a non-intersecting set of bug numbers for bugzilla bugs and github issues? > > > While I have no experience in bugzilla or github tooling, the two step > process described by Richard doesn't seem to be very complicated. > > > As mentioned by others, we have commits and tests (and sometimes source > files) that explicitly mention bug numbers. I do regularly look up bugs > from a decade ago to determine if a test or some code still has > relevance or not. If PR3214 can be one of two bugs, it does not only > increase lookup time but also add confusion to everyone involved. > > > Cheers, > >Johannes > > > > > -Tom > > > > > >> It sounds like we don't all agree that the last point is important, but if > >> we can achieve it without any significant additional cost, why not do so? > >> > >> Philip > >> > >> On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: > >>> In a previous discussion, one other suggestion had been to migrate > >>> all the bugzilla bugs to a separate initially-private "bug archive" > >>> repository in github. This has a few benefits: > >>>
Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)
On Fri, Apr 29, 2016 at 11:07 AM, Akira Hatanaka via cfe-commits < cfe-commits@lists.llvm.org> wrote: > If I add an assert to check (F != Flags) in setFlags, 2700+ out of 5000+ > clang regression tests fail. I haven’t figured out which parts of clang are > passing the same value to setFlags. > What are you initializing Flags to in the constructor? > On Apr 28, 2016, at 7:38 PM, Richard Smith via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > On Thu, Apr 28, 2016 at 7:34 PM, Akira Hatanaka via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> ahatanak added a comment. >> >> Thanks for the review. I committed the patch in r267956 and r267975. >> >> Do you think I should make setFlags(unsigned F) return early if F == >> Flags? > > > I don't think that should happen in practice, so it doesn't seem worth > checking. > > Repository: >> rL LLVM >> >> http://reviews.llvm.org/D19175 >> >> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Upgrading phabricator
Hi all, Phabricator is (finally) back online! Let me know if you have any feedback or problem :) Thanks, Eric On Thu, Sep 29, 2016 at 10:23 PM Eric Liu wrote: > According to top and iotop, mysqld is still working, and the progress bar > did move by a little bit, so I think it's just really slow. Apologies if > this is blocking you. > > On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Still no word on when it will be back up? It's not hung is it? :D > > On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > > On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Sorry for blocking everyone for so long. > > > No pb, thanks very much for taking care of it :) > > It has been more than a year since the last upgrade, and mysql is > adjusting schema for a table with ~150G data on a single VM instance. > > > 150GB? I’m very surprised there is so much data in our phab! That seems > huge... > > > My guess is that this includes all the diffs for every revision of every > review (as well as all the comments, etc), and it probably isn't as clever > with diffs as for example git. Which quite soon adds up to huge numbers > when you have tens of thousands of reviews. > > Purse speculation of course, I have never looked inside phabricator (or > for that matter, any other code-review tool). > > -- > Mats > > > — > Mehdi > > Sadly, the progress bar isn't giving useful information (plus I am not a > good system admin), so I couldn't tell the ETA... > > FYI: According to previous maintainer, it takes a couple of hours for the > last upgrade, so this should be done within a few hours (hopefully!). > > On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Is there any ETA? > > -Krzysztof > > On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote: > > That was a bad estimation. Database upgrade is taking time. > > > > On Thu, Sep 29, 2016 at 11:03 AM Eric Liu > <mailto:ioe...@google.com>> wrote: > > > > Hi all, > > > > Phabricator(reviews.llvm.org <http://reviews.llvm.org>) will be down > > for ~30 mins for an upgrade. Sorry for the short notice. > > > > Regards, > > Eric > > > > > > > > ___ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > ___________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
Thanks, Chandler, for all your work on this. I’m glad to see this moving forward. -Jim > On Jun 30, 2016, at 11:55 AM, Chandler Carruth via llvm-dev > wrote: > > Hello folks, > > As mentioned some time ago[1], we’ve had a long (looong) series of > discussions about establishing a code-of-conduct for the LLVM project as a > whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 > <http://reviews.llvm.org/D13741> code review. > > The discussion has largely died down for some time, and towards the end there > has been pretty wide support for the draft wording we have now. It isn’t > perfect, and there are still some important questions around forming the > advisory committee to handle reporting, but I think the wording is at a good > point of compromise in a challenging area. > > Based on the support, I’m going to land the patch that adds the draft. I’m > hoping this will immediately provide good advice and guidance, and I’m hoping > to see motion on setting up a reasonable advisory committee and resolving any > issues around reporting so we can make this an official part of the community. > > I sending this as a heads up so folks are aware, not to start a new > discussion thread. There are existing discussion threads[2] on llvm-dev if > folks want to join in active discussion or we can start fresh ones, but I > would encourage people to carefully read the discussion that has already > taken place to avoid revisiting areas that have already been heavily > discussed. > > Also, many thanks to the folks who provided all their opinions on the mailing > list threads and in person in long discussions about this topic. > > Thanks, > -Chandler > > [1]: Prior announcements: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > <http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html> > http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html > <http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html> > http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html > <http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html> > http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html > <http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html> > > [2]: Existing threads: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > <http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html> > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html > <http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html> > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html > <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html>___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] clang::VersionTuple
I'm good if Apple is good. > On May 8, 2018, at 11:31 AM, Frédéric Riss wrote: > > > >> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> >> >>> On May 8, 2018, at 9:47 AM, Zachary Turner >> <mailto:ztur...@google.com>> wrote: >>> >>> We don’t want the lowest levels of lldb to depend on clang. If this is >>> useful we should move it from clang to llvm and use llvm::VersionTuple >> >> I agree, though this move will cause merging issues for many that have >> repositories that link against older llvm/clang. Doesn't affect me anymore, >> but Apple will be affected. > > I’m not sure I understand what issues you’re referring to, we don’t link new > LLDBs to old clangs (and even if we did, it wouldn’t be something the that > drives community decisions). > > Fred > >> Greg >> >>> On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> No issues from me. >>> >>> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev >>> > mailto:lldb-dev@lists.llvm.org>> wrote: >>> > >>> > While moving Args around, I noticed that we have a bunch of >>> > functions/classes that pass/store version numbers as a triplet of integers >>> > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper class >>> > for that when I noticed clang::VersionTuple, which is pretty much what I >>> > wanted out of the box. >>> > >>> > Now there are small differences between this class, and what we have now: >>> > it has an extra fourth "build" field, and it uses only 31 bits to >>> > represent >>> > the values. None of these seem to matter (particularly as we are >>> > converting our representation into this struct in some places) that much, >>> > but before I go through the trouble of pulling this class into llvm >>> > (although technically possible, it seems wrong to pull a clang dependency >>> > at such a low level), I wanted to make sure we are able to use it. >>> > >>> > Do you see any reason why we could not replace our version triplets with >>> > clang::VersionTuple ? >>> > >>> > cheers, >>> > pl >>> > ___ >>> > lldb-dev mailing list >>> > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>> >>> _______ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?
On 2/12/21 1:49 AM, Omair Javaid wrote:
Hi Tom,
We at Linaro are maintaining LLVM Arm/AArch64 buildbots and want a host
buildbot for testing of release branches.
OK, that's great.
Kindly share the steps to do this. Do we have to host separate builbots for
tracking release branches or is it possible to track multiple branches by
existing buildbots assuming traffic on release branches is less frequent?
I've submitted a patch[1] to add the infrastructure for enabling builders
on the release branch. Once this patch or something similar gets applied
then we can start enabling individual builders. I'll follow up with you
once this patch lands.
-Tom
[1] https://reviews.llvm.org/D96046
On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote:
On 2/2/21 1:23 AM, Diana Picus wrote:
> Hi Tom,
>
> This sounds interesting! Would this also make it possible to
automatically get the release binaries from the buildbots, as opposed to manually
uploading to the FTP server?
>
Yes, this is something I would like to do. I think you could pretty easily
run
the test-release.sh script on the bot. The only issue is finding a way to
securely upload the binaries.
-Tom
> Cheers,
> Diana
>
> On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>>> wrote:
>
> Hi,
>
> I would like to improve the testing coverage in the release branch,
so if you
> are a buildbot owner and would like to enable your builder for the
release branch,
> let me know, and I can help get it enabled.
>
> Also, if you have any ideas for some more extensive testing that
might be too
> slow to run on the main branch, we may be able to enable it on the
release
> branch either running once per commit or once per tag.
>
> Thanks,
> Tom
>
> _______
> cfe-dev mailing list
> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
_______
LLVM Developers mailing list
llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
--
Omair Javaid
www.linaro.org <http://www.linaro.org>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries available
Hans, Are these new RC3 Windows binaries now with asserts disabled? Kind Regards Dan From: Hans Wennborg via cfe-dev<mailto:cfe-...@lists.llvm.org> Sent: 26 August 2016 22:30 To: llvm-dev<mailto:llvm-...@lists.llvm.org>; cfe-dev<mailto:cfe-...@lists.llvm.org>; LLDB Dev<mailto:lldb-dev@lists.llvm.org>; openmp-dev (openmp-...@lists.llvm.org)<mailto:openmp-...@lists.llvm.org> Cc: Release-testers<mailto:release-test...@lists.llvm.org> Subject: [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries available We're very very close to the final release. Source and binaries for LLVM-3.9.0-rc3 are available at http://llvm.org/pre-releases/3.9.0/#rc3 This release candidate is almost the same as rc2, with the following additional commits: r279224 - Minor change to OpenCL release notes r279260 - [lld] Add a note that 3.9 is a major milestone for us r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend. r279471 - [msan] Disable prlimit test on glibc < 2.13 r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC r279647 - [SCCP] Don't delete side-effecting instructions We're a little bit behind schedule and there is still an open release blocker in the Bugzilla, but I'm hopeful that we can wrap up the release next week. Thanks, Hans ___ cfe-dev mailing list cfe-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev _______ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: r341697 - warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'
On 11/17/2018 08:28 PM, Richard Smith wrote: > Procedurally, we shouldn't be making other changes at the same time as a > backport, but I'd sure like to see "stdlibc++" replaced with the correct > "libstdc++" (on trunk and branch). > When this gets fixes in trunk, let me know I can merge it to the branch. -Tom > On Sat, 17 Nov 2018, 19:00 Arthur O'Dwyer via cfe-commits > mailto:cfe-commits@lists.llvm.org> wrote: > > Peanut gallery says: I think the one remaining instance of `-std=libc++` > in the tests should be fixed at the same time. > > –Arthur > > On Sat, Nov 17, 2018 at 9:52 PM Richard Smith via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > > Good idea, this LG for a patch release. > > On Sat, 17 Nov 2018, 18:48 Shoaib Meenai via cfe-commits > mailto:cfe-commits@lists.llvm.org> wrote: > > Could we merge this into 7.0.1? It's a trivial typo fix, and the > error message could otherwise be confusing to users (someone brought this up > in IRC a few hours ago). > > __ __ > > *From: *cfe-commits <mailto:cfe-commits-boun...@lists.llvm.org>> on behalf of Alex Lorenz via > cfe-commits mailto:cfe-commits@lists.llvm.org>> > *Reply-To: *Alex Lorenz <mailto:arpha...@gmail.com>> > *Date: *Friday, September 7, 2018 at 12:01 PM > *To: *"cfe-commits@lists.llvm.org > <mailto:cfe-commits@lists.llvm.org>" <mailto:cfe-commits@lists.llvm.org>> > *Subject: *r341697 - warn_stdlibcxx_not_found: suggest > '-stdlib=libc++' instead of '-std' > > __ __ > > Author: arphaman > > Date: Fri Sep 7 11:59:45 2018 > > New Revision: 341697 > > __ __ > > URL: > https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D341697-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=MYePhuYEkBYd5aK7fqamBrBRJJGtvC-BPPojLInHah8&e= > > Log: > > warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of > '-std' > > __ __ > > Addresses first post-commit feedback for r335081 from Nico > > __ __ > > Modified: > > cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td > > cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp > > __ __ > > Modified: > cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td > > URL: > https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_include_clang_Basic_DiagnosticFrontendKinds.td-3Frev-3D341697-26r1-3D341696-26r2-3D341697-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=ZQcIenU2yQH3SmDrAhdXm2VKI10aP3_5IoBH-72HxYA&e= > > > == > > --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td > (original) > > +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri > Sep 7 11:59:45 2018 > > @@ -238,7 +238,7 @@ def warn_option_invalid_ocl_version : Wa > >"OpenCL version %0 does not support the option '%1'">, > InGroup; > > def warn_stdlibcxx_not_found : Warning< > > - "include path for stdlibc++ headers not found; pass > '-std=libc++' on the " > > + "include path for stdlibc++ headers not found; pass > '-stdlib=libc++' on the " > >"command line to use the libc++ standard library instead">, > >InGroup>; > > } > > __ __ > > Modified: cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp > > URL: > https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Frontend_warning-2Dstdlibcxx-2Ddarwin.cpp-3Frev-3D341697-26r1-3D341696-26r2-3D341697-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=YR_ENMKZ9M1ESvYMVXN6PlRtSZ8bXMsfvYf8QaBm5X4&e=
Re: [lldb-dev] [cfe-dev] LLVM 9.0.1-final has been tagged
On 01/09/2020 09:11 AM, Brian Cain wrote: > > > On Thu, Jan 9, 2020 at 12:29 AM Tom Stellard <mailto:tstel...@redhat.com>> wrote: > > On 01/08/2020 09:24 AM, Brian Cain wrote: > > Tom, the 9.0.1 final binaries didn't (yet?) make it to the github > release page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1 > > > > The binaries have been posted now. > > > I don't see the ubuntu 16 one that I uploaded there - > clang+llvm-9.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz > These are up now. -Tom > > > > I also checked https://releases.llvm.org/ because I recall some debate > or back-and-forth about where the releases should go and/or redirects or > links from one to the other. But they're not there either. > > > > I'm working on fixing the releases.llvm.org <http://releases.llvm.org> > page. > > -Tom > > > On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev > mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: > > > > Hi, > > > > I've just tagged the 9.0.1-final release. Testers can begin > uploading binaries. > > > > -Tom > > > > ___ > > cfe-dev mailing list > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > -- > > -Brian > > > > -- > -Brian ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC: Break/Watchpoint refactor
That solves the problem of excising the macros, but it replaces it with now
having to look at a superclass. Honestly that sounds like six one way, a half
dozen the other.
I wouldn't want this great overall list of improvements to get sidetracked over
bike shedding this, however. I'm fine with whatever approach is used, even if
it's the status quo.
Sean
> On Sep 27, 2016, at 3:43 PM, Zachary Turner wrote:
>
> One solution I've seen (I think boost does this as well) is to make a utility
> class called noncopyable that you can privately inherit from:
>
> class noncopyable {
> public:
>noncopyable(const noncopyable &) = delete;
>noncopyable &operator=(const noncopyable &other) = delete;
> };
>
> class Foo : private noncopyable {
> };
>
>
>
> On Tue, Sep 27, 2016 at 3:29 PM Sean Callanan <mailto:scalla...@apple.com>> wrote:
> The issue I have with the DISALLOW_ macro is that when you're looking to see
> what sort of constructors etc. are possible, you now have to look through a
> macro. Personally, I like to see what constructors are available on an
> object in one list, and not have to guess about whether e.g. a move
> constructor is present or disallowed.
>
> Sean
>
>> On Sep 27, 2016, at 3:24 PM, Jim Ingham > <mailto:jing...@apple.com>> wrote:
>>
>> Why? The macro states the intent explicitly, rather than having to deduce
>> it from details scattered through the class definition.
>>
>> Jim
>>
>>> On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>
>>> Doing it everywhere would be a public service IMO. I don't like macros
>>> either.
>>>
>>> Sean
>>>
>>>> On Sep 27, 2016, at 3:07 PM, Zachary Turner via lldb-dev
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>
>>>> FWIW LLVM removed all it's disallow copy / assign macros in favor of
>>>> explicitly writing it. I agree it's easier to just change the macro, but
>>>> I would just do what LLVM does as long as you don't mind the extra work.
>>>>
>>>> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>
>>>>
>>>> On 09/27/2016 03:37 PM, Enrico Granata wrote:
>>>>>
>>>>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
>>>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>>>
>>>>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro
>>>>>> DISALLOW_COPY_AND_ASSIGN
>>>>>
>>>>>
>>>>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That
>>>>> seems like a trivial change..
>>>>
>>>> That was my first thought as well. Still, I personally try to avoid
>>>> macros. On the other hand that one is simple enough that it may be
>>>> justified.
>>>>
>>>>>
>>>>> Thanks,
>>>>> - Enrico
>>>>> 📩 egranata@.com <> ☎️ 27683
>>>>>
>>>>
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [llvm-dev] Upgrading phabricator
I've switched the default email format to be plain text only now. This option should be per-user configurable, but somehow it is not shown in the "Settings"; I'll try if I can make the option personalized. Regarding new features and bug fixes in this upgrade, I don't really have a list since the Phabricator we are running is the open-source repo + some local modification. The last merge was more than one year ago, so I guess there should be a long list of new features and bug fixes. Some new features that I am aware of: - Syntax highlighting. - Patch size in email headers - HTML email (disabled) - More compatible with modern arc (the reason for this upgrade) - and more to be discovered! :) @Mehdi Deleting unposted inline comments works for me. At which patch did this issue occur? - Eric On Fri, Sep 30, 2016 at 7:39 AM Mehdi Amini wrote: > One of the new “feature” is that emails are HTML only right now. Not quite > nice for the archive (or for interacting by email). > See for instance: > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html > > (Also the funky "[Changed Subscribers] “ in the title) > > Another issue is that we can’t delete unposted inline comment anymore. > > — > Mehdi > > On Sep 29, 2016, at 9:35 PM, Zachary Turner via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > You mentioned this was for an upgrade. Are there any major new features or > bugfixes to be aware of? > On Thu, Sep 29, 2016 at 9:26 PM Eric Liu via llvm-commits < > llvm-comm...@lists.llvm.org> wrote: > > Hi all, > > Phabricator is (finally) back online! Let me know if you have any feedback > or problem :) > > Thanks, > Eric > > On Thu, Sep 29, 2016 at 10:23 PM Eric Liu wrote: > > According to top and iotop, mysqld is still working, and the progress bar > did move by a little bit, so I think it's just really slow. Apologies if > this is blocking you. > > On Thu, Sep 29, 2016 at 10:17 PM Zachary Turner via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Still no word on when it will be back up? It's not hung is it? :D > > On Thu, Sep 29, 2016 at 9:03 AM mats petersson via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > On 29 September 2016 at 16:11, Mehdi Amini via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > > On Sep 29, 2016, at 7:21 AM, Eric Liu via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Sorry for blocking everyone for so long. > > > No pb, thanks very much for taking care of it :) > > It has been more than a year since the last upgrade, and mysql is > adjusting schema for a table with ~150G data on a single VM instance. > > > 150GB? I’m very surprised there is so much data in our phab! That seems > huge... > > > My guess is that this includes all the diffs for every revision of every > review (as well as all the comments, etc), and it probably isn't as clever > with diffs as for example git. Which quite soon adds up to huge numbers > when you have tens of thousands of reviews. > > Purse speculation of course, I have never looked inside phabricator (or > for that matter, any other code-review tool). > > -- > Mats > > > — > Mehdi > > Sadly, the progress bar isn't giving useful information (plus I am not a > good system admin), so I couldn't tell the ETA... > > FYI: According to previous maintainer, it takes a couple of hours for the > last upgrade, so this should be done within a few hours (hopefully!). > > On Thu, Sep 29, 2016 at 4:04 PM Krzysztof Parzyszek via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Is there any ETA? > > -Krzysztof > > On 9/29/2016 5:34 AM, Eric Liu via llvm-dev wrote: > > That was a bad estimation. Database upgrade is taking time. > > > > On Thu, Sep 29, 2016 at 11:03 AM Eric Liu > <mailto:ioe...@google.com>> wrote: > > > > Hi all, > > > > Phabricator(reviews.llvm.org <http://reviews.llvm.org>) will be down > > for ~30 mins for an upgrade. Sorry for the short notice. > > > > Regards, > > Eric > > > > > > > > ___ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ >
Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD
Nah, its fine. Would have been completely easy to throw the necessary hardware at handling the load if I hadn't messed up the config. =] On Fri, Feb 17, 2017 at 2:39 PM Andrew Kelley via llvm-dev < llvm-...@lists.llvm.org> wrote: > Ah, sorry about that. Maybe I should have linked to the mailing list > archive instead of the phabricator code review page. > > On Fri, Feb 17, 2017 at 2:23 PM, Chandler Carruth via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > https://news.ycombinator.com/item?id=13670458 > > I'm restarting Phab with lots more cores / memory. Hopefully back up and > fast soon. > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] Trunk is now 13.0.0
Looks like it's https://bugs.llvm.org/show_bug.cgi?id=release-12.0.0 On Wed, Jan 27, 2021 at 9:58 AM Kadir Çetinkaya via cfe-dev < cfe-...@lists.llvm.org> wrote: > Is there a canonical bug for 12.0.0 release blockers where we can make > cherry-pick requests (I couldn't find any)? > > On Wed, Jan 27, 2021 at 6:46 AM Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> Hi, >> >> I've created the release/12.x branch and bumped the trunk version to >> 13.0.0. >> I'm planning to tag 12.0.0-rc1 on Wednesday, once I'm sure there are no >> major >> issues with the branch. >> >> -Tom >> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged
On Tue, Jan 8, 2019 at 11:25 PM Tom Stellard wrote: > On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote: > > Can the ubuntu tarballs be published to the download site? They're not > available yet. > > > > These are up on the download site now. > Tom, releases.llvm.org only shows Windows and FreeBSD tarballs for 7.0.1 from what I can see. Also, the front page of https://releases.llvm.org/ needs a new entry for 7.0.1 in the table under "Download". > > > On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev < > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> wrote: > > > > Ubuntu and SLES tarballs uploaded. I haven't had a chance to make a > SLES12 build yet, but I will try in the coming days. > > > > f7553a0d66092ca0bbe1eab2af405523a18bafba > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz > > 41db01a3b216df4fc22fae9c44e248889f9a01ed > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz > > caf149635742622a3a5b220146ff34f9202b8670 > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz > > 5e2b33ac129b8471683dccaeb2818004eb5acea8 > clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz > > > > > > On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers < > release-test...@lists.llvm.org <mailto:release-test...@lists.llvm.org>> > wrote: > > > > On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers < > release-test...@lists.llvm.org <mailto:release-test...@lists.llvm.org>> > wrote: > > > > > > I've tagged the 7.0.1 final release. Testers may begin > uploading binaries. > > > > Main test results on amd64-freebsd11 had 1 more Expected Pass > compared to 7.0.1 rc3, and no more Passes With Retry: > > > > Expected Passes: 52445(7.0.1 rc3: 52444) > > Passes With Retry : n/a(7.0.1 rc3: 1) > > Expected Failures : 232(7.0.1 rc3: 232) > > Unsupported Tests : 3687(7.0.1 rc3: 3687) > > Unexpected Passes : 1(7.0.1 rc3: 1) > > Unexpected Failures: 491(7.0.1 rc3: 491) > > > > Test-suite results on amd64-freebsd11 did not change: > > > > Expected Passes: 903(7.0.1 rc3: 903) > > Unexpected Failures: 3(7.0.1 rc3: 3) > > > > Test results on i386-freebsd11 had 1 more Expected Pass compared > to 7.0.1 rc3, and 3 less Unexpected Failures: > > > > Expected Passes: 50254(7.0.1 rc3: 50253) > > Passes With Retry : 2(7.0.1 rc3: n/a) > > Expected Failures : 226(7.0.1 rc3: 226) > > Unsupported Tests : 2502(7.0.1 rc3: 2502) > > Unexpected Failures: 272(7.0.1 rc3: 275) > > > > The test-suite still doesn't build on i386-freebsd11, but that > is a known issue. > > > > I have uploaded: > > > > SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = > 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407 > > SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = > 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36 > > > > -Dimitry > > > > _______ > > Release-testers mailing list > > release-test...@lists.llvm.org release-test...@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > > > > > -- > > -Brian > > _______ > > cfe-dev mailing list > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > ___ > > Release-testers mailing list > > release-test...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > -- -Brian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Mailing list changes this week
+1. And put it in the email (subject?). While it’s possible to derive a count
from a hash manually, better to have it in the email in the first place. You
can’t rely on order-of-email-delivery to reflect order-of-commit.
--paulr
From: llvm-dev On Behalf Of Shoaib Meenai via
llvm-dev
Sent: Wednesday, October 16, 2019 1:42 AM
To: tstel...@redhat.com; Mehdi AMINI
Cc: llvm-dev ; cfe-dev ;
openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev
Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
I thought we were just going to count commits on a particular branch and use
the (branch name, commit count) tuple as our monotonic incrementing identifier?
https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
From: cfe-dev
mailto:cfe-dev-boun...@lists.llvm.org>> on
behalf of cfe-dev mailto:cfe-...@lists.llvm.org>>
Organization: Red Hat
Reply-To: "tstel...@redhat.com<mailto:tstel...@redhat.com>"
mailto:tstel...@redhat.com>>
Date: Tuesday, October 15, 2019 at 10:13 PM
To: Mehdi AMINI mailto:joker@gmail.com>>
Cc: llvm-dev mailto:llvm-...@lists.llvm.org>>, cfe-dev
mailto:cfe-...@lists.llvm.org>>, "openmp-dev
(openmp-...@lists.llvm.org<mailto:openmp-...@lists.llvm.org>)"
mailto:openmp-...@lists.llvm.org>>, LLDB Dev
mailto:lldb-dev@lists.llvm.org>>
Subject: Re: [cfe-dev] Mailing list changes this week
On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard
mailto:tstel...@redhat.com>
<mailto:tstel...@redhat.com><mailto:tstel...@redhat.com%3e>> wrote:
On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> Hi Tom.
>
> One issue with this is that we don't have a clear "ordering" from linear
revision numbers from these emails. Have we looked into continuing to generate
our own emails per commits instead so that we control the format?
>
This actually what we are doing, we are listening for github commit events
and
then generating our own emails based on the data in the event. We can
format
the emails how ever we want, and we tried to match the current SVN format
exactly.
Ah great!
Is the some other information you would like to have in the emails to show
the
ordering?
The only thing I was looking to get was to continue to have a monotonic
incrementing integer for the revision instead of the git hash alone: I don't
know if `git llvm` has this feature yet but this was discussed a while ago (I
don't remember if we just mentioned counting the commits in the repo from the
beginning or using an invocation of `git describe` or something derived).
We talked about using `git describe` for this, but this would require that we
add tags to the master branch each time the version number was bumped. We
discussed this[1] last year, but deferred the decision, since we couldn't get
consensus on the tag name.
-Tom
[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
--
Mehdi
-Tom
> Thanks,
>
> --
> Mehdi
>
>
>
> On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev
mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>><mailto:cfe-...@lists.llvm.org%3e%3e>> wrote:
>
> Hi,
>
> We are going to start to switching from SVN commit emails to GitHub
commit
> emails this week. The only real change you should notice is that
> the revision number in the subject will be replaced with a git hash
and
> the diff links in the email will point to GitHub. Otherwise the
> content and format of the email should be the same.
>
> We are going to start by rolling this out for the openmp-commits list
> and then once that's working begin migrating the rest of the lists.
If you
> notice any issues with the new emails, please file a bug and mark it
> as a blocker of the github meta-bug (llvm.org/PR39393
<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_PR39393&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=eX8PTSE7QycIi5KeESJj4VzteOcs9k7RANSWPgiiQ2Q&e=
>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_PR39393&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=eX8PTSE7QycIi5KeESJj4VzteOcs9k7RANSWPgiiQ
Re: [lldb-dev] Leaks from static variables
Agreed that it’s a defect and should be addressed. It mostly a question of prioritization relative to other work, so knowing about a specific scenario where this is a pressing issue would be valuable. Kate Stone k8st...@apple.com <mailto:k8st...@apple.com> Xcode Low Level Tools > On Aug 1, 2016, at 3:25 PM, Zachary Turner via lldb-dev > wrote: > > If you're linking against liblldb you can't rely on the os cleaning up > because you could unload liblldb before shutting down the process. > > Also it's good practice to do explicit cleanup since its not always just a > simple matter of releasing resources, sometimes actual shutdown code needs to > be interspersed with the cleanup > On Mon, Aug 1, 2016 at 3:15 PM Kate Stone via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > Greg Clayton will almost certainly want to weigh in here when he returns next > week. Generally speaking, we’ve had a long tail of issues that only show up > during teardown that we’re avoiding. Leaking resources that will be > reclaimed by the OS when the process terminates is a non-issue. If there are > specific scenarios where a long-lived process leaks significant content that > isn’t an effective cache for subsequent use, please outline how that > manifests. > > Kate Stone k8st...@apple.com <mailto:k8st...@apple.com> > Xcode Low Level Tools > > >> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> > >> Hi lldb-dev, >> >> It looks like the debugger initializes static variables in llvm (see: >> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up. >> >> Does this cause memory leaks? I'd assumed that it's necessary to call >> llvm_shutdown() somewhere to avoid this kind of leak. >> >> Is there a buildbot I can check that tests an address-sanitized version of >> lldb? >> >> thanks, >> vedant > >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [Release-testers] 13.0.0-rc3 has been tagged
Hi Brian, Thank you for helping with the release! On 20/09/2021 18:40, Brian Cain via Openmp-dev wrote: I also disabled flang (-no-flang) because of memory exhaustion while trying to build. Is this increased memory consumption expected or could it be a bug? The memory usage of LLVM Flang was discussed in the past: * https://bugs.llvm.org/show_bug.cgi?id=50059 * https://lists.llvm.org/pipermail/flang-dev/2019-November/61.html It's not great, but sadly it is rather unlikely to improve in the near future. Thanks, -Andrzej $ cat clang+llvm-13.0.0-rc3-x86_64-linux-gnu-ubuntu-20.04.tar.xz.sha256 488ff13c9a54f6b7b2aeb26e930da7d72e32a15542929cd642fc0b7d37e79967 clang+llvm-13.0.0-rc3-x86_64-linux-gnu-ubuntu-20.04.tar.xz On Mon, Sep 13, 2021 at 11:40 PM Tom Stellard via Release-testers mailto:release-test...@lists.llvm.org>> wrote: Hi, I've tagged 13.0.0-rc3. This will likely be the last rc unless there are critical bugs that are found. Please test the release and report results. -Tom ___ Release-testers mailing list release-test...@lists.llvm.org <mailto:release-test...@lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers <https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers> -- -Brian ___ Openmp-dev mailing list openmp-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [RFC] Deprecate pre-commit email code reviews in favor of Phabricator
Code review guidelines patch is available for review: https://reviews.llvm.org/D103811. -- Krzysztof Parzyszek kparz...@quicinc.com<mailto:kparz...@quicinc.com> AI tools development From: David Blaikie Sent: Tuesday, May 18, 2021 3:01 PM To: Krzysztof Parzyszek Cc: llvm-dev ; clangd-...@lists.llvm.org; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org; cfe-...@lists.llvm.org; libcxx-...@lists.llvm.org; flang-...@lists.llvm.org; parallel_libs-...@lists.llvm.org Subject: [EXT] Re: [cfe-dev] [RFC] Deprecate pre-commit email code reviews in favor of Phabricator On Tue, May 18, 2021 at 6:50 AM Krzysztof Parzyszek mailto:kparz...@quicinc.com>> wrote: Post-commit reviews are conducted, in order of preference, on Phabricator, This still seems like a change in practice that I'm not in favor of, personally - due to the current divergence between email and phab review feedback. Yes, this would be one way to unify it - but I'm not sure it's necessarily the best one. I'd suggest leaving this to a separate proposal so as not to complicate/muddy the waters of the formalization of pre-commit review practice. I simply broke up the existing sentence from the documentation into two parts, one about pre-commit reviews and the other about all other code reviews (which are basically the post-commit reviews, although I’m open to corrections here). The first part was modified to reflect the proposed change, the second part was left unchanged. I think the issue is that the original phrasing was probably only intended to describe the preference for pre-commit review. (I think statements about post-commit review could reasonably read to be only those that say "post-commit review", in this ( https://llvm.org/docs/CodeReview.html#can-code-be-reviewed-after-it-is-committed ) section. So I think (at least in terms of how to read it in a way that matches existing practice) the original wording amounted to something like this: ... "post-commit review can use any of the tools listed below" ... ... "pre-commit review is done in this order of phab, email, etc... " ie: the post-commit review didn't have the same order of preference as pre-commit review. I'd probably pull out the post-commit review-specific wording back up to where post-commit review is discussed, and leave the rest of this to talk about pre-commit review (most of this document discussing unqualified "review" seems predominantly to be talking about "pre-commit review" except the part that talks about "post commit review"). Probably move the "on our web-based code-review tool (see Code Reviews with Phabricator), by email on the relevant project’s commit mailing list, on the project’s development list, or on the bug tracker." (without the "in order of preference") up to the "post-commit review" section, instead of referencing a version of it here. In this RFC I only want to change the part of the documentation that pertains specifically to pre-commit code reviews. If the wording I used creates confusion, what would you suggest instead? -- Krzysztof Parzyszek kparz...@quicinc.com<mailto:kparz...@quicinc.com> AI tools development From: David Blaikie mailto:dblai...@gmail.com>> Sent: Monday, May 17, 2021 4:40 PM To: Krzysztof Parzyszek mailto:kparz...@quicinc.com>> Cc: llvm-dev mailto:llvm-...@lists.llvm.org>>; clangd-...@lists.llvm.org<mailto:clangd-...@lists.llvm.org>; openmp-...@lists.llvm.org<mailto:openmp-...@lists.llvm.org>; lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>; cfe-...@lists.llvm.org<mailto:cfe-...@lists.llvm.org>; libcxx-...@lists.llvm.org<mailto:libcxx-...@lists.llvm.org>; flang-...@lists.llvm.org<mailto:flang-...@lists.llvm.org>; parallel_libs-...@lists.llvm.org<mailto:parallel_libs-...@lists.llvm.org> Subject: [EXT] Re: [cfe-dev] [RFC] Deprecate pre-commit email code reviews in favor of Phabricator On Mon, May 17, 2021 at 11:12 AM Krzysztof Parzyszek via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote: This is a revision of the previous RFC[1]. This RFC limits the scope to pre-commit reviews only. Statement: Our current code review policy states[2]: “Code reviews are conducted, in order of preference, on our web-based code-review tool (see Code Reviews with Phabricator), by email on the relevant project’s commit mailing list, on the project’s development list, or on the bug tracker.” This proposal is to limit pre-commit code reviews only to Phabricator. This would apply to all projects in the LLVM monorepo. With the change in effect, the amended policy would read: “Pre-commit code reviews are conducted on our web-based code-review tool (see Code Reviews with Phabricator). I'm with you here ^, this seems to document/formalize existing practice - though do
Re: [PATCH] D19175: Fix for PR27015 (variable template initialized with a generic lambda expression)
If I add an assert to check (F != Flags) in setFlags, 2700+ out of 5000+ clang regression tests fail. I haven’t figured out which parts of clang are passing the same value to setFlags. > On Apr 28, 2016, at 7:38 PM, Richard Smith via cfe-commits > wrote: > > On Thu, Apr 28, 2016 at 7:34 PM, Akira Hatanaka via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > ahatanak added a comment. > > Thanks for the review. I committed the patch in r267956 and r267975. > > Do you think I should make setFlags(unsigned F) return early if F == Flags? > > I don't think that should happen in practice, so it doesn't seem worth > checking. > > Repository: > rL LLVM > > http://reviews.llvm.org/D19175 <http://reviews.llvm.org/D19175> > > > > _______ > cfe-commits mailing list > cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits> > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] Forcing lldb to refresh process state
You need to send some sort of continue through the GDB remote interface. The only way to get a $T packet back is in response to a "?" packet or to a "vCont" or other continue or step packet. > On Aug 22, 2017, at 2:30 PM, Vadim Chugunov wrote: > > It does send '$T05...' in response, but it looks like lldb does not analyze > responses to manually sent packets. > > On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton <mailto:clayb...@gmail.com>> wrote: > If you do a reverse step it actually should send a process resumed and a > process stopped event. > > > On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev > <mailto:lldb-dev@lists.llvm.org>> wrote: > > > > I'm trying to reverse-step. So I think I'd need to refresh all thread > > states? > > > >> On Aug 18, 2017, at 4:50 PM, Jim Ingham >> <mailto:jing...@apple.com>> wrote: > >> > >> No, there hasn't been a need for this. > >> > >> What commands are you planning to send? Or equivalently, how much state > >> are you expecting to change? > >> > >> Jim > >> > >>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev > >>> mailto:lldb-dev@lists.llvm.org>> wrote: > >>> > >>> Hi, > >>> Is there any way to force lldb to refresh it's internal record of > >>> debuggee process state (as if it had just received a stop event)? I want > >>> to send a custom command to remote gdb process stub (via `process plugin > >>> packet send`). This works, but if the command alters debuggee state, > >>> lldb won't know about it. > >>> _______ > >>> lldb-dev mailing list > >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > >> > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
moved to https://reviews.llvm.org/D44321 it would've saved time if instructions had a TLDR that showed: ``` brew install homebrew/php/arcanist arc diff master # and following instructions ``` On Fri, Mar 9, 2018 at 8:44 AM, Ted Woodward via lldb-dev wrote: > Also see http://llvm.org/docs/Contributing.html > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > >> -Original Message- >> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide >> Italiano via lldb-dev >> Sent: Friday, March 09, 2018 10:27 AM >> To: Timothee Cour >> Cc: LLDB >> Subject: Re: [lldb-dev] how do i submit my patch for 'Support demangling for >> D >> symbols via dlopen' >> >> On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev > d...@lists.llvm.org> wrote: >> > I've registered to >> > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent >> > my patch via that email to lldb-comm...@lists.llvm.org but doesn't >> > appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how long >> > does it take for >> > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits to >> > subscribe? >> > >> >> Again, please sign-up for Phabricator as pointed out on the previous mail and >> submit the patch there https://llvm.org/docs/Phabricator.html >> >> > Still not sure why github PR's can't be accepted to remove all this >> > friction for outside developpers. >> > >> >> Because llvm main repo is still on svn. Once the migration to GitHub will >> happen, probably PR will be accepted at some point. >> >> Thanks, >> >> -- >> Davide >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] clang::VersionTuple
I was referring to the Swift and Apple internal branches. They tend to lock down against older llvm and clang repositories so when we put changes in llvm or clang that are required for LLDB, it makes merging a bit tougher in those cases. Again, I am not affected by this, just trying to watch out for you guys. Greg > On May 8, 2018, at 11:35 AM, Greg Clayton wrote: > > I'm good if Apple is good. > >> On May 8, 2018, at 11:31 AM, Frédéric Riss > <mailto:fr...@apple.com>> wrote: >> >> >> >>> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> >>> >>>> On May 8, 2018, at 9:47 AM, Zachary Turner >>> <mailto:ztur...@google.com>> wrote: >>>> >>>> We don’t want the lowest levels of lldb to depend on clang. If this is >>>> useful we should move it from clang to llvm and use llvm::VersionTuple >>> >>> I agree, though this move will cause merging issues for many that have >>> repositories that link against older llvm/clang. Doesn't affect me anymore, >>> but Apple will be affected. >> >> I’m not sure I understand what issues you’re referring to, we don’t link new >> LLDBs to old clangs (and even if we did, it wouldn’t be something the that >> drives community decisions). >> >> Fred >> >>> Greg >>> >>>> On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev >>>> mailto:lldb-dev@lists.llvm.org>> wrote: >>>> No issues from me. >>>> >>>> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev >>>> > mailto:lldb-dev@lists.llvm.org>> wrote: >>>> > >>>> > While moving Args around, I noticed that we have a bunch of >>>> > functions/classes that pass/store version numbers as a triplet of >>>> > integers >>>> > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper >>>> > class >>>> > for that when I noticed clang::VersionTuple, which is pretty much what I >>>> > wanted out of the box. >>>> > >>>> > Now there are small differences between this class, and what we have now: >>>> > it has an extra fourth "build" field, and it uses only 31 bits to >>>> > represent >>>> > the values. None of these seem to matter (particularly as we are >>>> > converting our representation into this struct in some places) that much, >>>> > but before I go through the trouble of pulling this class into llvm >>>> > (although technically possible, it seems wrong to pull a clang dependency >>>> > at such a low level), I wanted to make sure we are able to use it. >>>> > >>>> > Do you see any reason why we could not replace our version triplets with >>>> > clang::VersionTuple ? >>>> > >>>> > cheers, >>>> > pl >>>> > ___ >>>> > lldb-dev mailing list >>>> > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>>> >>>> ___ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>> >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
He said he did, so I don't know. Vadim, can you elaborate? When you run `lldb -P` from the command line, what do you see? On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I imagine that Hans doesn't have Python 3 installed on his system, so LLDB > didn't autoconfigure with Python support. > > On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > Does the 4.0 binary not work for you? It is the first release that contains > prebuilt lldb binary. > > Looks like the Python API is not included though. Do you know why it was > left out? > > > _______ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > _______ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Moderator needed for lldb-commits
Hello Tanya, I am new to the team but I am also happy to help. -Shafik > On Jul 9, 2018, at 1:53 PM, Raphael Isemann via lldb-dev > wrote: > > Hi Tanya, > > I'm also in! > > - Raphael > Am Mo., 9. Juli 2018 um 13:50 Uhr schrieb Jonas Devlieghere via > lldb-dev : >> >> Hi Tanya, >> >> I'd be happy to take care of this! >> >> Cheers, >> Jonas >> >>> On Jul 6, 2018, at 6:01 PM, Tanya Lattner via lldb-dev >>> wrote: >>> >>> LLDB Developers, >>> >>> Moderators are needed for the lldb-commits mailing list. Is anyone >>> interested in helping out? >>> >>> Thanks, >>> Tanya >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> _______ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > _______ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC: Break/Watchpoint refactor
Doing it everywhere would be a public service IMO. I don't like macros either. Sean > On Sep 27, 2016, at 3:07 PM, Zachary Turner via lldb-dev > wrote: > > FWIW LLVM removed all it's disallow copy / assign macros in favor of > explicitly writing it. I agree it's easier to just change the macro, but I > would just do what LLVM does as long as you don't mind the extra work. > > On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > > > On 09/27/2016 03:37 PM, Enrico Granata wrote: >> >>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> * Prefer explicitly deleted copy ctor / assignments over multiline macro >>> DISALLOW_COPY_AND_ASSIGN >> >> >> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That >> seems like a trivial change.. > > That was my first thought as well. Still, I personally try to avoid macros. > On the other hand that one is simple enough that it may be justified. > >> >> Thanks, >> - Enrico >> 📩 egranata@.com ☎️ 27683 >> > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > _______ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 3 tagged
Yes, the removal of RISC-V from LLVM_ALL_TARGETS was intentional. See https://reviews.llvm.org/D36538 and the accompanying message to llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116347.html for the rationale. Thanks, Simon From: Release-testers [release-testers-boun...@lists.llvm.org] on behalf of Bero Rosenkränzer via Release-testers [release-test...@lists.llvm.org] Sent: 26 August 2017 13:00 To: Hans Wennborg Cc: llvm-dev; Release-testers; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev Subject: Re: [Release-testers] [5.0.0 Release] Release Candidate 3 tagged Working well here so far. Is the removal of the RISCVCodeGen, RISCVDesc and RISCVInfo libraries that were in rc2 intentional? ttyl bero On 26 August 2017 at 00:52, Hans Wennborg via Release-testers wrote: > Dear testers, > > 5.0.0-rc3 was just tagged. > > This is a release candidate in the real sense: if nothing bad comes up > in testing, this is what the release is going to look like. > > Please build, test and upload binaries to the sftp (use the > /data/testers-uploads/ directory) and let me know what issues remain. > > I know we're a little bit behind schedule, but hopefully we can get to > 'final' soon. > > Cheers, > Hans > ___ > Release-testers mailing list > release-test...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ Release-testers mailing list release-test...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers _______ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [PATCH] D42157: [clang-cl] Let /FA output use intel assembly.
r322674 attempts to fix. On Wed, Jan 17, 2018 at 10:54 AM, Yvan Roux via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hi Nico, > > On 17 January 2018 at 14:35, Nico Weber via Phabricator via > cfe-commits wrote: > > thakis closed this revision. > > thakis added a comment. > > > > r322652, thanks! > > This commit broke ARM bots: > http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14839 > > Cheers, > Yvan > > > > > https://reviews.llvm.org/D42157 > > > > > > > > ___ > > cfe-commits mailing list > > cfe-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] clang::VersionTuple
> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev > wrote: > > > >> On May 8, 2018, at 9:47 AM, Zachary Turner > <mailto:ztur...@google.com>> wrote: >> >> We don’t want the lowest levels of lldb to depend on clang. If this is >> useful we should move it from clang to llvm and use llvm::VersionTuple > > I agree, though this move will cause merging issues for many that have > repositories that link against older llvm/clang. Doesn't affect me anymore, > but Apple will be affected. I’m not sure I understand what issues you’re referring to, we don’t link new LLDBs to old clangs (and even if we did, it wouldn’t be something the that drives community decisions). Fred > Greg > >> On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> No issues from me. >> >> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev >> > mailto:lldb-dev@lists.llvm.org>> wrote: >> > >> > While moving Args around, I noticed that we have a bunch of >> > functions/classes that pass/store version numbers as a triplet of integers >> > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper class >> > for that when I noticed clang::VersionTuple, which is pretty much what I >> > wanted out of the box. >> > >> > Now there are small differences between this class, and what we have now: >> > it has an extra fourth "build" field, and it uses only 31 bits to represent >> > the values. None of these seem to matter (particularly as we are >> > converting our representation into this struct in some places) that much, >> > but before I go through the trouble of pulling this class into llvm >> > (although technically possible, it seems wrong to pull a clang dependency >> > at such a low level), I wanted to make sure we are able to use it. >> > >> > Do you see any reason why we could not replace our version triplets with >> > clang::VersionTuple ? >> > >> > cheers, >> > pl >> > _______ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] clang::VersionTuple
> On May 8, 2018, at 11:37 AM, Greg Clayton wrote: > > I was referring to the Swift and Apple internal branches. They tend to lock > down against older llvm and clang repositories so when we put changes in llvm > or clang that are required for LLDB, it makes merging a bit tougher in those > cases. Again, I am not affected by this, just trying to watch out for you > guys. I understand and I appreciate it, I was just worried that I’m missing something obvious. We branch LLDB at the same time as LLVM so that’s not actually an issue. Of course, it might cause merge conflicts or make it harder to cherry-pick patches, but that's just living downstream. Fred > Greg > > >> On May 8, 2018, at 11:35 AM, Greg Clayton > <mailto:clayb...@gmail.com>> wrote: >> >> I'm good if Apple is good. >> >>> On May 8, 2018, at 11:31 AM, Frédéric Riss >> <mailto:fr...@apple.com>> wrote: >>> >>> >>> >>>> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev >>>> mailto:lldb-dev@lists.llvm.org>> wrote: >>>> >>>> >>>> >>>>> On May 8, 2018, at 9:47 AM, Zachary Turner >>>> <mailto:ztur...@google.com>> wrote: >>>>> >>>>> We don’t want the lowest levels of lldb to depend on clang. If this is >>>>> useful we should move it from clang to llvm and use llvm::VersionTuple >>>> >>>> I agree, though this move will cause merging issues for many that have >>>> repositories that link against older llvm/clang. Doesn't affect me >>>> anymore, but Apple will be affected. >>> >>> I’m not sure I understand what issues you’re referring to, we don’t link >>> new LLDBs to old clangs (and even if we did, it wouldn’t be something the >>> that drives community decisions). >>> >>> Fred >>> >>>> Greg >>>> >>>>> On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev >>>>> mailto:lldb-dev@lists.llvm.org>> wrote: >>>>> No issues from me. >>>>> >>>>> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev >>>>> > mailto:lldb-dev@lists.llvm.org>> wrote: >>>>> > >>>>> > While moving Args around, I noticed that we have a bunch of >>>>> > functions/classes that pass/store version numbers as a triplet of >>>>> > integers >>>>> > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper >>>>> > class >>>>> > for that when I noticed clang::VersionTuple, which is pretty much what I >>>>> > wanted out of the box. >>>>> > >>>>> > Now there are small differences between this class, and what we have >>>>> > now: >>>>> > it has an extra fourth "build" field, and it uses only 31 bits to >>>>> > represent >>>>> > the values. None of these seem to matter (particularly as we are >>>>> > converting our representation into this struct in some places) that >>>>> > much, >>>>> > but before I go through the trouble of pulling this class into llvm >>>>> > (although technically possible, it seems wrong to pull a clang >>>>> > dependency >>>>> > at such a low level), I wanted to make sure we are able to use it. >>>>> > >>>>> > Do you see any reason why we could not replace our version triplets with >>>>> > clang::VersionTuple ? >>>>> > >>>>> > cheers, >>>>> > pl >>>>> > ___ >>>>> > lldb-dev mailing list >>>>> > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>>>> >>>>> ___ >>>>> lldb-dev mailing list >>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>>> >>>> ___ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: r273950 -
Any tests? On Mon, Jun 27, 2016 at 5:12 PM, Nico Weber via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Did you land this intentionally? What was the commit message supposed to > be? > > On Mon, Jun 27, 2016 at 6:11 PM, Chris Dewhurst via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: lerochris >> Date: Mon Jun 27 17:11:12 2016 >> New Revision: 273950 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=273950&view=rev >> Log: (empty) >> >> Modified: >> cfe/trunk/lib/Basic/Targets.cpp >> >> Modified: cfe/trunk/lib/Basic/Targets.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=273950&r1=273949&r2=273950&view=diff >> >> == >> --- cfe/trunk/lib/Basic/Targets.cpp (original) >> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Jun 27 17:11:12 2016 >> @@ -6594,6 +6594,8 @@ public: >>PtrDiffType = SignedLong; >>break; >> } >> + >> +MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64; >>} >> >>void getTargetDefines(const LangOptions &Opts, >> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > > > _______ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] How to link lldb on i386
cross building on a 64-bit machine using a 64-bit toolchain is what we have to do on Windows. On Mon, May 23, 2016 at 2:21 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Don't generate debug info would be one that comes to mind. The other is to > cross build for i386 on a 64 bit machine. > > Greg > > > On May 22, 2016, at 3:36 AM, Sylvestre Ledru via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hello, > > > > Lately, I haven't been able to link lldb because it uses too much memory: > > > > /usr/bin/ld: final link failed: Memory exhausted > > > > As reported here: > > > > https://llvm.org/bugs/show_bug.cgi?id=27237 > > > > > > (yes, I use shared libraries) > > > > Any workaround? > > > > Thanks, > > Sylvestre > > PS: please cc me ! > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] lldb-mi functionality
-llvm-dev We support most MI commands and lldb-mi can be used alongside with Eclipse. So probably it would work also with gdbgui. They are pretty compatible :) On Tue, Mar 14, 2017 at 6:08 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Not too much documentation unfortunately, but I'm cc'ing lldb-dev@. > Hopefully one of the people who have worked on authoring / maintaining this > will see it and chime in. > > On Fri, Mar 10, 2017 at 7:36 PM Chad Smith via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> Is there any documentation on what machine interface (mi) commands are >> implemented in lldb-mi, and how compatible those commands are with gdb's mi? >> >> I'm asking for this project: https://github.com/cs01/gdbgui >> >> ___________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- - Ilia ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [cfe-users] cfe-users Digest, Vol 62, Issue 11
unsubscribe
On Thu, Mar 22, 2018 at 3:02 PM via cfe-users
wrote:
> Send cfe-users mailing list submissions to
> cfe-users@lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
> or, via email, send a message with subject or body 'help' to
> cfe-users-requ...@lists.llvm.org
>
> You can reach the person managing the list at
> cfe-users-ow...@lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-users digest..."
>
>
> Today's Topics:
>
>1. tooling clang 7.0 option parser extra argument
> (Steven Varga via cfe-users)
>
>
> --
>
> Message: 1
> Date: Thu, 22 Mar 2018 00:37:35 -0400
> From: Steven Varga via cfe-users
> To: cfe-users@lists.llvm.org
> Subject: [cfe-users] tooling clang 7.0 option parser extra argument
> Message-ID:
> <
> cafkvq9ms1xcycw+3gbkwjxuhez5naqai-fjrdbd8bcff5dt...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I was wondering it is possible to parse extra arguments with option parser?
>
> best,
> steven
>
> static llvm::cl::OptionCategory MyToolCategory("h5cpp options");
> ...
> int main(int argc, const char **argv) {
>
> CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
> ClangTool Tool(OptionsParser.getCompilations(),
> OptionsParser.getSourcePathList());
>
> }
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.llvm.org/pipermail/cfe-users/attachments/20180322/135eb202/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
>
> --
>
> End of cfe-users Digest, Vol 62, Issue 11
> *
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
Also see http://llvm.org/docs/Contributing.html -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide > Italiano via lldb-dev > Sent: Friday, March 09, 2018 10:27 AM > To: Timothee Cour > Cc: LLDB > Subject: Re: [lldb-dev] how do i submit my patch for 'Support demangling for D > symbols via dlopen' > > On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev d...@lists.llvm.org> wrote: > > I've registered to > > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent > > my patch via that email to lldb-comm...@lists.llvm.org but doesn't > > appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how long > > does it take for > > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits to > > subscribe? > > > > Again, please sign-up for Phabricator as pointed out on the previous mail and > submit the patch there https://llvm.org/docs/Phabricator.html > > > Still not sure why github PR's can't be accepted to remove all this > > friction for outside developpers. > > > > Because llvm main repo is still on svn. Once the migration to GitHub will > happen, probably PR will be accepted at some point. > > Thanks, > > -- > Davide > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] clang::VersionTuple
> On May 8, 2018, at 9:47 AM, Zachary Turner wrote: > > We don’t want the lowest levels of lldb to depend on clang. If this is useful > we should move it from clang to llvm and use llvm::VersionTuple I agree, though this move will cause merging issues for many that have repositories that link against older llvm/clang. Doesn't affect me anymore, but Apple will be affected. Greg > On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > No issues from me. > > > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev > > mailto:lldb-dev@lists.llvm.org>> wrote: > > > > While moving Args around, I noticed that we have a bunch of > > functions/classes that pass/store version numbers as a triplet of integers > > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper class > > for that when I noticed clang::VersionTuple, which is pretty much what I > > wanted out of the box. > > > > Now there are small differences between this class, and what we have now: > > it has an extra fourth "build" field, and it uses only 31 bits to represent > > the values. None of these seem to matter (particularly as we are > > converting our representation into this struct in some places) that much, > > but before I go through the trouble of pulling this class into llvm > > (although technically possible, it seems wrong to pull a clang dependency > > at such a low level), I wanted to make sure we are able to use it. > > > > Do you see any reason why we could not replace our version triplets with > > clang::VersionTuple ? > > > > cheers, > > pl > > _______ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] How soon after the GitHub migration should committing with git-llvm become optional?
I'm also a strong proponent of not requiring the wrapper.
The linear history piece was important enough to make the cost worth
it. The extra branches piece really isn't. If someone creates a branch
that's not supposed to exist, we just delete it. No big deal. It will
happen, but the cost is so low I don't worry about it.
There's a bunch of things in our developer policy we don't enforce
except through social means. I don't see any reason why the "no
branches" thing needs to be special.
If we really want some automation, a simple script that polls for new
branches every five minutes and deletes them unless on a while list
would work just fine. :)
Philip
On 10/15/19 9:26 PM, Mehdi AMINI via cfe-dev wrote:
On Tue, Oct 15, 2019 at 12:26 PM Hubert Tong via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
I say retire it instantly.
+1. It has never been a real requirement to use the script. Using
native svn is still viable until the point of the migration.
It was a requirement for the "linear history" feature. With GitHub
providing this now, I'm also +1 on retiring the tool unless there is a
another use that can be articulated for it?
--
Mehdi
> On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev
mailto:cfe-...@lists.llvm.org>> wrote:
>
> Hi,
>
> I mentioned this in my email last week, but I wanted to
start a new
> thread to get everyone's input on what to do about the
git-llvm script
> after the GitHub migration.
>
> The original plan was to require the use of the git-llvm
script when
> committing to GitHub even after the migration was complete.
> The reason we decided to do this was so that we could
prevent developers
> from accidentally pushing merge commits and making the
history non-linear.
>
> Just in the last week, the GitHub team completed the
"Require Linear
> History" branch protection, which means we can now enforce
linear
> history server side and do not need the git-llvm script to
do this.
>
> With this new development, the question I have is when
should the
> git-llvm script become optional? Should we make it optional
immediately,
> so that developers can push directly using vanilla git from
day 1, or should we
> wait a few weeks/months until things have stabilized to make
it optional?
>
> Thanks,
> Tom
>
>
>
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
LLVM Developers mailing list
llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
LLVM Developers mailing list
llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______
cfe-dev mailing list
cfe-...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
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 [UPDATED]
On 4/21/20 6:50 PM, Richard Smith wrote: On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev mailto:cfe-...@lists.llvm.org> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: > > +1 to James's take > > I'd prefer simplicity of implementation over perfection here. > > If we end up with two different bug numbering systems, that's a problem that we will be paying for for many years. It's worth some investment now to avoid that problem. And it doesn't seem like it really requires much investment. > > Here's another path we could take: > > 1) Fork the llvm repository to a private "bugs" repository. Mirror the bugzilla issues there. Iterate until we're happy, as per James's proposal. > 2) Sync the forked repository to the llvm repository, delete the llvm repository, rename "bugs" to "llvm", and make it public. > > Then we'll have the first N bugs in llvm-project/llvm being *exactly* the bugzilla bugs, and we'll have excised the existing github issues that we want to pretend never existed anyway. > > > I think we've missed an important step in the planning here: we've not agreed on a set of goals for the transition. Here are mine: > > * We end up with one single issue tracking system containing all issues, both old and new, both open and closed. > * All links and references to existing bugs still work. > * We have a single bug numbering system covering all bugs, and old bugs retain their numbers. Why are the bug numbers important? These numbers appear all over our codebase. PR[0-9] appears 3592 times in Clang testcases, plus 45 times in Clang source code and 119 times more as the file names of Clang testcases. If we add inconvenience to looking up all of those, that makes maintenance harder each time someone wants to look one of those up. (That's probably a ~weekly occurrence for me.) For this use case, a simple script and bulk change to update references in source repo means the numbering can change arbitrarily. ~4k small mechanical changes is just not that much to review for a one time update assuming you trust the number remapping script and are just looking for overly aggressive regex matches. (I don't have any quick fixes for your other mentioned cases.) Also, bug numbers appear in other bugs. I would assume we're not going to be able to reliably figure out which numbers appearing in a bug are bug numbers during the import process, so those numbers will persist into the github issues world. (In addition, I'm sure multiple groups have their own tracking systems, web pages, documentation, etc. that contain references to LLVM PR numbers. But maybe we shouldn't worry too much about that.) Could you help give some example use cases that require having a non-intersecting set of bug numbers for bugzilla bugs and github issues? It makes conversing about bug numbers more difficult if you need to clarify which system you're talking about. As a minor example, we'd have to avoid saying "PR" for the new system in order to avoid confusion, and get used to some new terminology, and probably not use "bug 1234" to describe either system, because that would be ambiguous. None of these individual factors seems like a huge disruption, but they all seem like inconvenience we should prefer to avoid if possible. -Tom > > It sounds like we don't all agree that the last point is important, but if we can achieve it without any significant additional cost, why not do so? > > Philip > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: >> In a previous discussion, one other suggestion had been to migrate all the bugzilla bugs to a separate initially-private "bug archive" repository in github. This has a few benefits: >> 1. If the migration is messed up, the repo can be deleted, and the process run again, until we get a result we like. >> 2. The numbering can be fully-controlled. >> Once the bugs are migrated to /some/ github repository, individual issues can then be "moved" between repositories, and github will redirect from the movefrom-repository's bug to the target repository's bug. >> >> We could also just have llvm.org/PR### <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> be the url
Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On 04/21/2020 06:50 PM, Richard Smith wrote: > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: > > > > +1 to James's take > > > > I'd prefer simplicity of implementation over perfection here. > > > > If we end up with two different bug numbering systems, that's a problem > that we will be paying for for many years. It's worth some investment now to > avoid that problem. And it doesn't seem like it really requires much > investment. > > > > Here's another path we could take: > > > > 1) Fork the llvm repository to a private "bugs" repository. Mirror the > bugzilla issues there. Iterate until we're happy, as per James's proposal. > > 2) Sync the forked repository to the llvm repository, delete the llvm > repository, rename "bugs" to "llvm", and make it public. > > > > Then we'll have the first N bugs in llvm-project/llvm being *exactly* > the bugzilla bugs, and we'll have excised the existing github issues that we > want to pretend never existed anyway. > > > > > > I think we've missed an important step in the planning here: we've not > agreed on a set of goals for the transition. Here are mine: > > > > * We end up with one single issue tracking system containing all > issues, both old and new, both open and closed. > > * All links and references to existing bugs still work. > > * We have a single bug numbering system covering all bugs, and old > bugs retain their numbers. > > Why are the bug numbers important? > > > These numbers appear all over our codebase. PR[0-9] appears 3592 times in > Clang testcases, plus 45 times in Clang source code and 119 times more as the > file names of Clang testcases. If we add inconvenience to looking up all of > those, that makes maintenance harder each time someone wants to look one of > those up. (That's probably a ~weekly occurrence for me.) > Having a new number scheme does not mean we have to break all the llvm.org/PR links. These could still be used to look up old bugs even if we change bug notation to GH-. > Also, bug numbers appear in other bugs. I would assume we're not going to be > able to reliably figure out which numbers appearing in a bug are bug numbers > during the import process, so those numbers will persist into the github > issues world. > This is a good point and not something that I had thought of. I think maintaining the bug links in the bugs is something that could be done during the import. e.g replace references to bug# x with links to llvm.org/PR. We will have to investigate this more. Thanks, Tom > (In addition, I'm sure multiple groups have their own tracking systems, web > pages, documentation, etc. that contain references to LLVM PR numbers. But > maybe we shouldn't worry too much about that.) > > Could you help give some example use cases that require having > a non-intersecting set of bug numbers for bugzilla bugs and github issues? > > > It makes conversing about bug numbers more difficult if you need to clarify > which system you're talking about. As a minor example, we'd have to avoid > saying "PR" for the new system in order to avoid confusion, and get used to > some new terminology, and probably not use "bug 1234" to describe either > system, because that would be ambiguous. None of these individual factors > seems like a huge disruption, but they all seem like inconvenience we should > prefer to avoid if possible. > > -Tom > > > > > > It sounds like we don't all agree that the last point is important, but > if we can achieve it without any significant additional cost, why not do so? > > > > Philip > > > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: > >> In a previous discussion, one other suggestion had been to migrate > all the bugzilla bugs to a separate initially-private "bug archive" > repository in github. This has a few benefits: > >> 1. If the migration is messed up, the repo can be deleted, and the > process run again, until we get a result we like. > >> 2. The numbering can be fully-c
Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work
llvm-config.h doesn't provide the necessary macros. I've applied a different fix for out-of-tree builds in r279112. On Wed, Aug 17, 2016 at 11:51 PM, Vedant Kumar via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Done in clang/r279035. > > thanks, > vedant > > > On Aug 17, 2016, at 7:43 AM, Will Dietz via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > > > (Seems to fix the build here, FWIW. If sounds reasonable can someone > commit this? Thanks!) > > > > ~Will > > > > On Wed, Aug 17, 2016 at 9:39 AM Will Dietz wrote: > > This is the first use of "llvm/Config/config.h" in the clang tree, which > breaks out-of-tree builds for me (since llvm's config.h isn't installed). > > > > Would using "llvm/Config/llvm-config.h" suffice instead? I'm trying that > now... > > > > ~Will > > > > On Wed, Aug 17, 2016 at 8:36 AM Joerg Sonnenberger via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > On Wed, Aug 17, 2016 at 01:05:08AM -, Richard Smith via cfe-commits > wrote: > > > Author: rsmith > > > Date: Tue Aug 16 20:05:07 2016 > > > New Revision: 278882 > > > > > > URL: http://llvm.org/viewvc/llvm-project?rev=278882&view=rev > > > Log: > > > If possible, set the stack rlimit to at least 8MiB on cc1 startup, and > work > > > around a Linux kernel bug where the actual amount of available stack > may be a > > > *lot* lower than the rlimit. > > > > Can you please restrict this to Linux? I'm quite opposed to overriding > > system default limits, they exist for a reason. > > > > Joerg > > ___ > > cfe-commits mailing list > > cfe-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ > > cfe-commits mailing list > > cfe-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] Connecting to lldb-rpc-server
I am gonna echo Kate's question, but delve one level deeper Why do you want to send commands to LLDB from a different process? We have a bunch of different extension points in LLDB, so it's possible that what you're trying to do is actually already possible > On Oct 7, 2016, at 10:41 AM, Rex Fenley via lldb-dev > wrote: > > Hi Kate, > > I'm trying to connect to the running instance of lldb in Xcode to send > commands to it from a different process :) > > On Fri, Oct 7, 2016 at 10:27 AM, Kate Stone <mailto:k8st...@apple.com>> wrote: > The RPC mechanism used in Xcode 8 is not a part of the open source LLDB > project and should be treated as an implementation detail of Xcode. What are > you trying to accomplish? > > Kate Stone k8st...@apple.com <mailto:k8st...@apple.com> > Xcode Low Level Tools > >> On Oct 6, 2016, at 6:11 PM, Rex Fenley via lldb-dev > <mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having trouble. >> >> This doesn't seem to work to list the hosts. >> rpcinfo -p lldb-rpc-server >> >> Can't contact rpcbind on lldb-rpc-server >> >> >> rpcinfo: RPC: Unknown host >> >> Am I doing this correctly? >> >> -- >> Rex Fenley | IOS DEVELOPER >> >> >> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | >> FOLLOW US <https://twitter.com/remindhq> | LIKE US >> <https://www.facebook.com/remindhq>___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > > > > -- > Rex Fenley | IOS DEVELOPER > > > Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | > FOLLOW US <https://twitter.com/remindhq> | LIKE US > <https://www.facebook.com/remindhq>___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> Thanks, - Enrico 📩 egranata@.com ☎️ 27683 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] GitHub Survey - Results
I’m working on it. — Mehdi > On Nov 2, 2016, at 1:43 PM, Zachary Turner via lldb-dev > wrote: > > It would be nice if the slides containing the pie-graphs showed the original > question that people were responding to. It's a little hard to make sense of > the answers if we can't see (and don't remember) the question. > > On Wed, Nov 2, 2016 at 12:39 PM Renato Golin via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > Folks, > > Please note that the survey is still open! > > But it's almost time for the US LLVM meeting and I'd like to give > everybody the ability to inspect the results before entering the BoF > session tomorrow. > > Here is a zip file with the raw results (minus emails) of the data up > until this morning, and a short presentation with a summary and my > personal pick of the comments. > > http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip > <http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip> > > I tried to focus on less on the positive comments and more on the > negative ones for all topics, because they're the ones that will make > the difference. I've also tried hard to be completely impartial, just > presenting the results. > > If you haven't yet submitted, please do. We'll be looking at the data > and sharing it on the Bof. Mehdi will collate the BoF results and once > the survey is finally closed, I'll share the raw results again. > > Enjoy! > --renato > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [RFC] Deprecate email code reviews in favor of Phabricator
I'll defer to Christian the discussion about this section. +Christian -- Krzysztof Parzyszek kparz...@quicinc.com AI tools development -Original Message- From: cfe-dev On Behalf Of Kevin P. Neal via cfe-dev Sent: Monday, May 3, 2021 1:57 PM To: Krzysztof Parzyszek via llvm-dev Cc: clangd-...@lists.llvm.org; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org; cfe-...@lists.llvm.org; libcxx-...@lists.llvm.org; flang-...@lists.llvm.org; parallel_libs-...@lists.llvm.org Subject: [EXT] Re: [cfe-dev] [llvm-dev] [RFC] Deprecate email code reviews in favor of Phabricator On Mon, May 03, 2021 at 05:24:24PM +, Krzysztof Parzyszek via llvm-dev wrote: >This section presents a potential future evolution of the review >process. Christian has conducted experiments suggesting that we can >replace the XXX-commits mailing lists with notifications directly from >Phabricator: Wouldn't this make it more difficult for sites that archive the lists? Right now it all works. If the lists were eliminated then it would be harder to archive. Not impossible, but it would be more work. Plus, how long would it take for archive sites to switch over? How much history would only exist in Phab's database? Couldn't the commit lists be made read-only except from Phab? That would force reviews to happen on Phab but otherwise keep all existing email setups working. -- "A method for inducing cats to exercise consists of directing a beam of invisible light produced by a hand-held laser apparatus onto the floor ... in the vicinity of the cat, then moving the laser ... in an irregular way fascinating to cats,..." -- US patent 5443036, "Method of exercising a cat" ___ cfe-dev mailing list cfe-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev _______ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3
Windows LLDB is done On Thu, May 26, 2016 at 2:39 AM Daniel Sanders via lldb-dev < lldb-dev@lists.llvm.org> wrote: > All the MIPS buildbots are ready too. > > > > *From:* llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] *On Behalf Of > *NAKAMURA > Takumi via llvm-dev > *Sent:* 25 May 2016 23:03 > *To:* Chris Bieneman; llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; > lldb-dev@lists.llvm.org > *Subject:* Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum > version to 3.4.3 > > > > I am ready, regarding to, http://bb.pgr.jp/ > > On Wed, May 25, 2016 at 5:54 AM Chris Bieneman wrote: > > Meant to send this yesterday, but I want to remind everyone that we’re > going to be raising the CMake minimum version to 3.4.3 next week. > > If you maintain bots please ensure that your bots are updated by end of > day 5/29 so that we can move on 5/30 (next Monday). > > I have already heard from most bot owners either saying they had made the > change, or scheduled to make it. > > If you have any questions or concerns please let me know. > > Thank you, > -Chris > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
I'm not able to repro at head (on Windows 7). On Tue, Dec 6, 2016 at 10:48 AM, Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > I've also never seen either problem. I'm not debugging Windows apps, but > Hexagon apps, running lldb and the Hexagon simulator on Win7. > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eli > > Zaretskii via lldb-dev > > Sent: Tuesday, December 06, 2016 10:39 AM > > To: Zachary Turner > > Cc: lldb-dev@lists.llvm.org > > Subject: Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7 > > > > > From: Zachary Turner > > > Date: Tue, 06 Dec 2016 16:22:51 + > > > > > > I have never seen either of those problems, but I can test it out and > see if I > > can reproduce. > > > > Thanks. > > > > If you are unable to reproduce, I wonder why it happens to me. The > system > > where I installed lldb is just a vanilla Windows 7 box. > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-instr not working
Are there instructions for this somewhere? If not, can we get some on the site? > On Mar 23, 2020, at 1:31 PM, Jonas Devlieghere via lldb-dev > wrote: > > Hi Walter, > > lldb-instr needs compile_commands.json file to figure out the exact compiler > invocation for every file. Can you verify that the file exists in the > directory you're running lldb-instr from? > > Cheers, > Jonas > > On Mon, Mar 23, 2020 at 1:29 PM Walter via lldb-dev <mailto:lldb-dev@lists.llvm.org>> wrote: > Hi, I've recently tried to use lldb-instr, as mentioned in > https://lldb.llvm.org/resources/sbapi.html > <https://lldb.llvm.org/resources/sbapi.html>, but I'm having the following > issue when running it on darwin. > > ./lldb-instr > > LLVM ERROR: Unable to find target for this triple (no targets are > > registered) > > Is this a known issue? Or should lldb-instr be built in a special way to make > it aware of the local compilation target? > > Does anyone know anything about this? > > Thanks! > > - Walter > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ 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] How soon after the GitHub migration should committing with git-llvm become optional?
On Tue, Oct 15, 2019 at 9:26 PM Mehdi AMINI via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > On Tue, Oct 15, 2019 at 12:26 PM Hubert Tong via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev < >> llvm-...@lists.llvm.org> wrote: >> >>> I say retire it instantly. >>> >> +1. It has never been a real requirement to use the script. Using native >> svn is still viable until the point of the migration. >> > > It was a requirement for the "linear history" feature. With GitHub > providing this now, I'm also +1 on retiring the tool unless there is a > another use that can be articulated for it? > I believe one thing mentioned was that if the tool was required, it could be used to enforce a do-not-branch policy. That's the thing I've seen discussed so far. (& questions as to whether that's worth it, whether there's other ways to enforce it, etc) - Dave > > -- > Mehdi > > > >> >> >>> >>> > On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev < >>> cfe-...@lists.llvm.org> wrote: >>> > >>> > Hi, >>> > >>> > I mentioned this in my email last week, but I wanted to start a new >>> > thread to get everyone's input on what to do about the git-llvm script >>> > after the GitHub migration. >>> > >>> > The original plan was to require the use of the git-llvm script when >>> > committing to GitHub even after the migration was complete. >>> > The reason we decided to do this was so that we could prevent >>> developers >>> > from accidentally pushing merge commits and making the history >>> non-linear. >>> > >>> > Just in the last week, the GitHub team completed the "Require Linear >>> > History" branch protection, which means we can now enforce linear >>> > history server side and do not need the git-llvm script to do this. >>> > >>> > With this new development, the question I have is when should the >>> > git-llvm script become optional? Should we make it optional >>> immediately, >>> > so that developers can push directly using vanilla git from day 1, or >>> should we >>> > wait a few weeks/months until things have stabilized to make it >>> optional? >>> > >>> > Thanks, >>> > Tom >>> > >>> > >>> > >>> > >>> > >>> > _______ >>> > cfe-dev mailing list >>> > cfe-...@lists.llvm.org >>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Mailing list changes this week
On 10/16/2019 07:23 AM, Robinson, Paul wrote: > +1. And put it in the email (subject?). While it’s possible to derive a > count from a hash manually, better to have it in the email in the first > place. You can’t rely on order-of-email-delivery to reflect order-of-commit. > I spent some time today looking into what it would take to add the commit number into the email. Implementing this will add some extra complexity to the emailer script and add another point of failure for us. We also can't guarantee to always have it since at some point we may want to start using github's standard commit emails. I think we should just wait and see how things go without having a commit number in the email. It's easy to generate the number locally from a git hash if needed. If it becomes a major inconvenience to not have it in the email, we can always look at adding it in later. -Tom > --paulr > > > > *From:* llvm-dev *On Behalf Of *Shoaib > Meenai via llvm-dev > *Sent:* Wednesday, October 16, 2019 1:42 AM > *To:* tstel...@redhat.com; Mehdi AMINI > *Cc:* llvm-dev ; cfe-dev ; > openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev > > *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week > > > > I thought we were just going to count commits on a particular branch and use > the (branch name, commit count) tuple as our monotonic incrementing > identifier? > https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git > > > > > > *From: *cfe-dev <mailto:cfe-dev-boun...@lists.llvm.org>> on behalf of cfe-dev > mailto:cfe-...@lists.llvm.org>> > *Organization: *Red Hat > *Reply-To: *"tstel...@redhat.com <mailto:tstel...@redhat.com>" > mailto:tstel...@redhat.com>> > *Date: *Tuesday, October 15, 2019 at 10:13 PM > *To: *Mehdi AMINI mailto:joker@gmail.com>> > *Cc: *llvm-dev mailto:llvm-...@lists.llvm.org>>, > cfe-dev mailto:cfe-...@lists.llvm.org>>, "openmp-dev > (openmp-...@lists.llvm.org <mailto:openmp-...@lists.llvm.org>)" > mailto:openmp-...@lists.llvm.org>>, LLDB Dev > mailto:lldb-dev@lists.llvm.org>> > *Subject: *Re: [cfe-dev] Mailing list changes this week > > > > On 10/15/2019 09:44 PM, Mehdi AMINI wrote: > > On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard <mailto:tstel...@redhat.com> <mailto:tstel...@redhat.com> > <mailto:tstel...@redhat.com%3e>> wrote: > > On 10/15/2019 09:24 PM, Mehdi AMINI wrote: > > > Hi Tom. > > > > > > One issue with this is that we don't have a clear "ordering" from > linear revision numbers from these emails. Have we looked into continuing to > generate our own emails per commits instead so that we control the format? > > > > > This actually what we are doing, we are listening for github commit > events and > > then generating our own emails based on the data in the event. We > can format > > the emails how ever we want, and we tried to match the current SVN > format exactly. > > Ah great! > > > > Is the some other information you would like to have in the emails > to show the > > ordering? > > The only thing I was looking to get was to continue to have a monotonic > incrementing integer for the revision instead of the git hash alone: I don't > know if `git llvm` has this feature yet but this was discussed a while ago (I > don't remember if we just mentioned counting the commits in the repo from the > beginning or using an invocation of `git describe` or something derived). > > > > We talked about using `git describe` for this, but this would require that we > > add tags to the master branch each time the version number was bumped. We > > discussed this[1] last year, but deferred the decision, since we couldn't get > > consensus on the tag name. > > > > -Tom > > > > [1] > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e= > > > > -- > > Mehdi > > > > -Tom > > > Thanks, > > > > > > -- > > > Mehdi > > > > > > > > > > > > On Tue, Oct 15, 2019 at 9:07 PM T
Re: [lldb-dev] [cfe-dev] [llvm-dev] December LLVM bay-area social is this Thursday!
Mostly worried because we talked to them before and they wanted us to buy a banquet menu at A lot of dollars. On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev wrote: > I reached out to Steins (which is right across the street) to see if they > can host us. I’ll keep y’all posted, it seemed optimistic in our phone chat. > > > On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev < > cfe-...@lists.llvm.org> wrote: > > Oof. :( > > Offhand, I can’t think of any place in particular. As one might imagine, > accommodating 50+ people isn’t always super easy for places to do. > > Suggestions welcome! > > On Tue, Dec 24, 2019 at 10:27 AM Sean Silva wrote: > >> It looks like Tied House will be shutting down :( Do we have a >> replacement venue? >> >> >> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits >> >> >> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev < >> llvm-...@lists.llvm.org> wrote: >> >>> We'll be at Tied House as usual, starting on Thursday the 5th at 7pm! >>> >>> If you can, help us plan and RSVP here: >>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb >>> >>> See everyone there! >>> >> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> ___________ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged
On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote: > Can the ubuntu tarballs be published to the download site? They're not > available yet. > These are up on the download site now. -Tom > On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev > mailto:cfe-...@lists.llvm.org>> wrote: > > Ubuntu and SLES tarballs uploaded. I haven't had a chance to make a > SLES12 build yet, but I will try in the coming days. > > f7553a0d66092ca0bbe1eab2af405523a18bafba > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz > 41db01a3b216df4fc22fae9c44e248889f9a01ed > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz > caf149635742622a3a5b220146ff34f9202b8670 > clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz > 5e2b33ac129b8471683dccaeb2818004eb5acea8 > clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz > > > On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers > mailto:release-test...@lists.llvm.org>> > wrote: > > On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers > mailto:release-test...@lists.llvm.org>> > wrote: > > > > I've tagged the 7.0.1 final release. Testers may begin uploading > binaries. > > Main test results on amd64-freebsd11 had 1 more Expected Pass > compared to 7.0.1 rc3, and no more Passes With Retry: > > Expected Passes: 52445(7.0.1 rc3: 52444) > Passes With Retry : n/a(7.0.1 rc3: 1) > Expected Failures : 232(7.0.1 rc3: 232) > Unsupported Tests : 3687(7.0.1 rc3: 3687) > Unexpected Passes : 1(7.0.1 rc3: 1) > Unexpected Failures: 491(7.0.1 rc3: 491) > > Test-suite results on amd64-freebsd11 did not change: > > Expected Passes: 903(7.0.1 rc3: 903) > Unexpected Failures: 3(7.0.1 rc3: 3) > > Test results on i386-freebsd11 had 1 more Expected Pass compared to > 7.0.1 rc3, and 3 less Unexpected Failures: > > Expected Passes: 50254(7.0.1 rc3: 50253) > Passes With Retry : 2(7.0.1 rc3: n/a) > Expected Failures : 226(7.0.1 rc3: 226) > Unsupported Tests : 2502(7.0.1 rc3: 2502) > Unexpected Failures: 272(7.0.1 rc3: 275) > > The test-suite still doesn't build on i386-freebsd11, but that is a > known issue. > > I have uploaded: > > SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = > 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407 > SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = > 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36 > > -Dimitry > > ___ > Release-testers mailing list > release-test...@lists.llvm.org <mailto:release-test...@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > -- > -Brian > _______ > cfe-dev mailing list > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > ___ > Release-testers mailing list > release-test...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: r273950 -
Reverted it in r273994. I expect you may recommit it. ;) On Tue, Jun 28, 2016 at 9:12 AM Nico Weber via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Did you land this intentionally? What was the commit message supposed to > be? > > On Mon, Jun 27, 2016 at 6:11 PM, Chris Dewhurst via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: lerochris >> Date: Mon Jun 27 17:11:12 2016 >> New Revision: 273950 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=273950&view=rev >> Log: (empty) >> >> Modified: >> cfe/trunk/lib/Basic/Targets.cpp >> >> Modified: cfe/trunk/lib/Basic/Targets.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=273950&r1=273949&r2=273950&view=diff >> >> == >> --- cfe/trunk/lib/Basic/Targets.cpp (original) >> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Jun 27 17:11:12 2016 >> @@ -6594,6 +6594,8 @@ public: >>PtrDiffType = SignedLong; >>break; >> } >> + >> +MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64; >>} >> >>void getTargetDefines(const LangOptions &Opts, >> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4
>From chatting with Tim it sounds like at least one lldb bot uses the ToT compiler - we should probably verify that not only does it use that to build lldb but uses it for the tests. That'll get us at least some testing here. -eric On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I believe we are good, but it would be good to verify via testing once a > compiler becomes available. > > Greg > > > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > This might affect us. Do we handle it correctly? > > > > https://reviews.llvm.org/D16697 > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > _______ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [PATCH] D18479: [CodeGenCXX] Fix ItaniumCXXABI::getAlignmentOfExnObject to return 8-byte alignment on Darwin
> On Mar 25, 2016, at 2:23 PM, Akira Hatanaka via cfe-commits
> wrote:
>
>>
>> On Mar 25, 2016, at 2:06 PM, David Majnemer via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>
>>
>>
>> On Fri, Mar 25, 2016 at 12:57 PM, Akira Hatanaka via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> ahatanak created this revision.
>> ahatanak added a reviewer: rjmccall.
>> ahatanak added a subscriber: cfe-commits.
>>
>> r246985 made changes to give a higher alignment for exception objects on the
>> grounds that Itanium says _Unwind_Exception should be "double-word" aligned
>> and the structure is normally declared with __attribute__((aligned))
>> guaranteeing 16-byte alignment. It turns out that libc++abi doesn't declare
>> the structure with __attribute__((aligned)) and therefore only guarantees
>> 8-byte alignment on 32-bit and 64-bit platforms. This caused a crash in some
>> cases when the backend emitted SIMD store instructions that requires 16-byte
>> alignment (such as movaps).
>>
>> This patch makes ItaniumCXXABI::getAlignmentOfExnObject return an 8-byte
>> alignment on Darwin to fix the crash.
>>
>> http://reviews.llvm.org/D18479 <http://reviews.llvm.org/D18479>
>>
>> Files:
>> lib/CodeGen/ItaniumCXXABI.cpp
>> test/CodeGenCXX/eh.cpp
>>
>> Index: test/CodeGenCXX/eh.cpp
>> ===
>> --- test/CodeGenCXX/eh.cpp
>> +++ test/CodeGenCXX/eh.cpp
>> @@ -448,5 +448,27 @@
>>}
>> }
>>
>> +namespace test17 {
>> +class BaseException {
>> +private:
>> + int a[4];
>> +public:
>> + BaseException() {};
>> +};
>> +
>> +class DerivedException: public BaseException {
>> +};
>> +
>> +int foo() {
>> + throw DerivedException();
>> + // The alignment passed to memset is 8, not 16, on Darwin.
>> +
>> + // CHECK: [[T0:%.*]] = call i8* @__cxa_allocate_exception(i64 16)
>> + // CHECK-NEXT: [[T1:%.*]] = bitcast i8* [[T0]] to
>> %"class.test17::DerivedException"*
>> + // CHECK-NEXT: [[T2:%.*]] = bitcast %"class.test17::DerivedException"*
>> [[T1]] to i8*
>> + // CHECK-NEXT: call void @llvm.memset.p0i8.i64(i8* [[T2]], i8 0, i64 16,
>> i32 8, i1 false)
>> +}
>> +}
>> +
>> // CHECK: attributes [[NUW]] = { nounwind }
>> // CHECK: attributes [[NR]] = { noreturn }
>> Index: lib/CodeGen/ItaniumCXXABI.cpp
>> ===
>> --- lib/CodeGen/ItaniumCXXABI.cpp
>> +++ lib/CodeGen/ItaniumCXXABI.cpp
>> @@ -163,8 +163,17 @@
>>/// we assume that alignment here. (It's generally 16 bytes, but
>>/// some targets overwrite it.)
>>CharUnits getAlignmentOfExnObject() {
>> -auto align =
>> CGM.getContext().getTargetDefaultAlignForAttributeAligned();
>> -return CGM.getContext().toCharUnitsFromBits(align);
>> +unsigned Align;
>> +
>> +// Alignment is 8 for darwin since libc++abi doesn't declare
>> +// _Unwind_Exception with __attribute__((aligned)) and therefore doesn't
>> +// guarantee 16-byte alignment.
>> +if (CGM.getContext().getTargetInfo().getTriple().isOSDarwin())
>>
>> What about Linux/FreeBSD targets which use libc++abi?
>>
>
> Is there a way to detect whether libc++abi is used?
>
I wasn’t planning to fix this for Linux or FreeBSD because I don’t know whether
that is what people want. If the library being used returns an object that is
16-byte aligned (does libsupc++ return an aligned object?), my change would
unnecessarily pessimize the code.
>> + Align = 64;
>> +else
>> + Align = CGM.getContext().getTargetDefaultAlignForAttributeAligned();
>> +
>> +return CGM.getContext().toCharUnitsFromBits(Align);
>>}
>>
>>void emitRethrow(CodeGenFunction &CGF, bool isNoReturn) override;
>>
>>
>>
>> ___________
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
I expect Rafael's concern is because the code also says: In addition, violations of this code outside these spaces may, in rare cases, affect a person's ability to participate within them. So it can apply outside spaces explicitly sponsored by LLVM, in undefined circumstances. --paulr From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Daniel Berlin via cfe-dev Sent: Thursday, June 30, 2016 1:37 PM To: Rafael Espíndola Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Subject: Re: [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct On Thu, Jun 30, 2016 at 1:23 PM, Rafael Espíndola mailto:llvm-...@lists.llvm.org>> wrote: I am strongly opposed to it as it stands. Who decided this and with what authority? As written the code of conduct tries restrict the acceptable opinions one may voice even in channels not related to llvm at all. errr, it says: "This code of conduct applies to all spaces managed by the LLVM project or The LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, LLVM vents such as the developer meetings and socials, and any other forums created by the project that the community uses for communication. " How does this cover channels not related to llvm? With this in place I will not consider myself a member of the llvm community anymore and would be terrified to interact with another llvm developer in a social setting. That would be sad, but i guess i'm not sure what is causing that. Is it that there is discretion in there that you are afraid may apply to you if taken to some extreme? Rafael On 30 June 2016 at 14:55, Chandler Carruth via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote: > Hello folks, > > As mentioned some time ago[1], we’ve had a long (looong) series of > discussions about establishing a code-of-conduct for the LLVM project as a > whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 > code review. > > The discussion has largely died down for some time, and towards the end > there has been pretty wide support for the draft wording we have now. It > isn’t perfect, and there are still some important questions around forming > the advisory committee to handle reporting, but I think the wording is at a > good point of compromise in a challenging area. > > Based on the support, I’m going to land the patch that adds the draft. I’m > hoping this will immediately provide good advice and guidance, and I’m > hoping to see motion on setting up a reasonable advisory committee and > resolving any issues around reporting so we can make this an official part > of the community. > > I sending this as a heads up so folks are aware, not to start a new > discussion thread. There are existing discussion threads[2] on llvm-dev if > folks want to join in active discussion or we can start fresh ones, but I > would encourage people to carefully read the discussion that has already > taken place to avoid revisiting areas that have already been heavily > discussed. > > Also, many thanks to the folks who provided all their opinions on the > mailing list threads and in person in long discussions about this topic. > > Thanks, > -Chandler > > [1]: Prior announcements: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html > http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html > http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html > > [2]: Existing threads: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org<mailto:cfe-...@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ LLVM Developers mailing list llvm-...@lists.llvm.org<mailto:llvm-...@lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb
Hi and thank you for the detailed reply, Tamas. Ok, so I’ll cope with increased size of lldb-server for AArch64. As a side note – is there any publicly available roadmap for LLDB on Android, that covers features to implement\issues to fix? I suggest that the community will greatly appreciate to get a glimpse on the direction of development for that target. Regards, Mikhail From: Tamas Berghammer [mailto:tbergham...@google.com] Sent: Tuesday, March 1, 2016 1:34 PM To: Pavel Labath ; Mikhail Filimonov Cc: lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb As Pavel mentioned the unreasonable large size for lldb-server is caused by the fact that we are relying on the liker to remove the unused code and it can't do too good job because we have lot of unreasonable dependencies. The size difference between arm and arrahc64 caused by several reason: * On arm we compile to thumb2 instruction set what is in average ~30% smaller then the arm (and aarch64) instruction set. Before this change the size of lldb-server on arm was ~14MB * We have Safe ICF (identical code folding) enabled for arm what reduces the binary size by 5-10%. It is not enabled for aarch64 because last time I checked there was still some issue in ld.gold when using ICF on aarch64. It should be already fixed upstream but haven't reached the NDK yet. * The aarch64 lldb-server capable of debugging both arm and aarch64 applications so it contains a bit more code because of this (e.g. 2 spearate register context) Optimizing the size of both binary is possible (and we want to do it sooner or later) but because of the reasons I listed the arm one will stay much smaller then the aarch64 one. Tamas On Tue, Mar 1, 2016 at 9:18 AM Pavel Labath via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: Hi, so the problem here is that we are currently relying on the linker to remove code that we don't need, and it can't always do a good job in figuring out which code is not used due to complex dependencies. So, innocent-looking changes in the code can pull in lots of transitive dependencies, even though they are not used. I suspect something like that is going on here, although we should keep in mind that arm64 code is less dense naturally. Any help on this front will be welcome, although it probably won't be trivial, as we have probably picked off the low-hanging fruit already. That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to your cmake line. We use that, although I can't say how much it affects the size of the resulting binary. help that helps, pl On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: > Hello, fellow developers and congratulations with long awaited 3.8 Release. > > I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release] > RC3 source is so much bigger than its ARM counterpart. > See the numbers: > 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64 > 9570916 Feb 29 22:23 lldb-server-3.8.0-arm > lldb-server-3.8.0-aarch64: ELF 64-bit LSB executable, ARM aarch64, version 1 > (SYSV), statically linked, stripped > lldb-server-3.8.0-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 > (SYSV), statically linked, stripped > > My build configuration is MinSizeRel in both cases: > cmake -GNinja > -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git > -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake > -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android > -DANDROID_ABI=aarch64 > -DCMAKE_CXX_COMPILER_VERSION=4.9 > -DLLVM_TARGET_ARCH=aarch64 > -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android > -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen > -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen > > cmake -GNinja > -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git > -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake > -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain > -DANDROID_ABI=armeabi > -DCMAKE_CXX_COMPILER_VERSION=4.9 > -DLLVM_TARGET_ARCH=arm > -DLLVM_HOST_TRIPLE=arm-unknown-linux-android > -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen > -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen > > Maybe I need some additional settings to be set for AArch64 case? > > Regards, > Mikhail > > -Original Message- > From: lldb-dev > [mailto:lldb-dev-boun...@lists.llvm.org<mailto:lldb-dev-boun...@lists.llvm.org>] > On Behalf Of Hans Wennborg via lldb-dev > Sent: Wednesday, February 24, 2016 12:51 AM > To: release-test...@lists.llvm.org<mailto:release-test...@lists.llvm.org> > Cc: llvm-dev mailto:llvm-...@lists.llvm.org>>; > cfe-dev mailto:cfe-...@lists.llvm.org>>; openmp-dev > (openmp-...@lists.llvm.org<mailto:openmp-...@lists.
Re: [lldb-dev] [Release-testers] [llvm-dev] [5.0.0 Release] Release Candidate 3 tagged
Hello I am not sure to understand how this relates to the 5.0.0 work? For now, it is broken because of a gcc bug: https://bugs.llvm.org/show_bug.cgi?id=34150 I am planning to upgrade the gcc version to 4.9 to workaround this issue. Probably this week. Sylvestre Le 28/08/2017 à 09:40, Andrew Kelley via Release-testers a écrit : > trusty on apt.llvm.org <http://apt.llvm.org> is behind the others by 9 > days and is missing the latest rc3 release. Can we get an update on this? > > Regards, > Andrew > > On Fri, Aug 25, 2017 at 6:52 PM, Hans Wennborg via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > > Dear testers, > > 5.0.0-rc3 was just tagged. > > This is a release candidate in the real sense: if nothing bad comes up > in testing, this is what the release is going to look like. > > Please build, test and upload binaries to the sftp (use the > /data/testers-uploads/ directory) and let me know what issues remain. > > I know we're a little bit behind schedule, but hopefully we can get to > 'final' soon. > > Cheers, > Hans > _______ > LLVM Developers mailing list > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > ___ > Release-testers mailing list > release-test...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On 4/22/20 2:35 PM, Richard Smith wrote:
On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev
mailto:cfe-...@lists.llvm.org>> wrote:
On 4/21/20 6:50 PM, Richard Smith wrote:
On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev
mailto:cfe-...@lists.llvm.org>
<mailto:cfe-...@lists.llvm.org
<mailto:cfe-...@lists.llvm.org>>> wrote:
>
> +1 to James's take
>
> I'd prefer simplicity of implementation over perfection
here.
>
> If we end up with two different bug numbering systems,
that's a problem that we will be paying for for many years.
It's worth some investment now to avoid that problem. And it
doesn't seem like it really requires much investment.
>
> Here's another path we could take:
>
> 1) Fork the llvm repository to a private "bugs" repository.
Mirror the bugzilla issues there. Iterate until we're happy,
as per James's proposal.
> 2) Sync the forked repository to the llvm repository,
delete the llvm repository, rename "bugs" to "llvm", and make
it public.
>
> Then we'll have the first N bugs in llvm-project/llvm being
*exactly* the bugzilla bugs, and we'll have excised the
existing github issues that we want to pretend never existed
anyway.
>
>
> I think we've missed an important step in the planning
here: we've not agreed on a set of goals for the transition.
Here are mine:
>
> * We end up with one single issue tracking system
containing all issues, both old and new, both open and closed.
> * All links and references to existing bugs still work.
> * We have a single bug numbering system covering all bugs,
and old bugs retain their numbers.
Why are the bug numbers important?
These numbers appear all over our codebase. PR[0-9] appears 3592
times in Clang testcases, plus 45 times in Clang source code and
119 times more as the file names of Clang testcases. If we add
inconvenience to looking up all of those, that makes maintenance
harder each time someone wants to look one of those up. (That's
probably a ~weekly occurrence for me.)
For this use case, a simple script and bulk change to update
references in source repo means the numbering can change
arbitrarily. ~4k small mechanical changes is just not that much
to review for a one time update assuming you trust the number
remapping script and are just looking for overly aggressive regex
matches.
It's not quite as straightforward as you're suggesting: such a simple
script would break a bunch of our CodeGen tests that match mangled
names, if the length of any bug identifier changes. A grep for
'_Z.*PR[0-9]' indicates that there are at least 254 of those that
might need manual updating if we took this path.
We have an auto-updater for most llc scripts, but point taken. My main
point was this was one time, not that the one time was trivial.
(I don't have any quick fixes for your other mentioned cases.)
Another case I didn't think of before, but that seems very important:
bug numbers appear in commit messages, and are primary context in
understanding what the commit is doing and why. [We *could* go on a
bulk history editing spree to fix those commit messages up (git
filter-branch actually makes this fairly easy) -- but that too would
create a little churn as everyone would needs to rebase all their work
in progress on the rewritten master, and honestly, that sounds a lot
scarier than any of the other things we've considered in this thread :)]
Agreed, history rewrite as a solution here should be rejected out of
hand. :)
Also, bug numbers appear in other bugs. I would assume we're not
going to be able to reliably figure out which numbers appearing
in a bug are bug numbers during the import process, so those
numbers will persist into the github issues world.
(In addition, I'm sure multiple groups have their own tracking
systems, web pages, documentation, etc. that contain references
to LLVM PR numbers. But maybe we shouldn't worry too much about
that.)
Could you help give some example use cases that require having
a non-intersecting set of bug numbers for bugzilla bugs and
github issues?
It makes conversing about bug numbers more difficult if you need
to clarify which system
Re: [lldb-dev] [cfe-dev] [3.7 Release] 3.7.0-final has been tagged
The last one has finished and it was ok too. From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg [h...@chromium.org] Sent: 01 September 2015 18:43 To: Daniel Sanders Cc: llvm-dev; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Ledru; Renato Golin; Ben Pope; Sebastian Dreßler; Pavel Labath; Ed Maste Subject: Re: [cfe-dev] [3.7 Release] 3.7.0-final has been tagged Thanks! Let me know how the last one goes. On Tue, Sep 1, 2015 at 8:16 AM, Daniel Sanders wrote: > clang+llvm-3.7.0-mips-linux-gnu.tar.xz > All ok > > clang+llvm-3.7.0-mipsel-linux-gnu.tar.xz > All ok > > clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to > Mips) > 22 of 23 test suite runs ok. The 23rd is still running and is ok so far. > > From: cfe-dev [cfe-dev-boun...@lists.llvm.org] on behalf of Hans Wennborg via > cfe-dev [cfe-...@lists.llvm.org] > Sent: 28 August 2015 02:46 > To: llvm-dev; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; > openmp-...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Ledru; > Renato Golin; Ben Pope; Sebastian Dreßler; Pavel Labath; Ed Maste > Subject: [cfe-dev] [3.7 Release] 3.7.0-final has been tagged > > On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote: >> 3.7.0-rc4 has just been tagged. It is identical to rc3, plus: >> >> - r245902: Revert r245355: change of clang-tools-extra symlink in the >> release script >> - r245947: Merge of r245927: Fix LLDB build on MIPS >> - r245948: Deprecate the DataLayout on the TargetMachine, and backport >> the 3.8 API >> - Changes to the ReleaseNotes. >> >> Those changes should all be safe, and I expect this to be an extremely >> short cycle. >> >> Please build and test. If no new issues arise, I plan to tag this as >> 'final' tomorrow or Friday so we can ship the release next week. > > I have promoted RC4 to final; 3.7.0 has reached its final state. > > Thanks for all your hard work so far. Please build and upload binaries > with "-final", and let's ship this next week! > > Thanks, > Hans > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.
Thank you for that! From: Shoaib Meenai [mailto:smee...@fb.com] Sent: Tuesday, January 8, 2019 4:48 PM To: David Majnemer Cc: Keane, Erich ; cfe-commits@lists.llvm.org; Martin Storsjo Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types. I sent out https://reviews.llvm.org/D56466 to clarify the comment accordingly. From: David Majnemer mailto:david.majne...@gmail.com>> Date: Tuesday, January 8, 2019 at 3:21 PM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: "Keane, Erich" mailto:erich.ke...@intel.com>>, "cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" mailto:cfe-commits@lists.llvm.org>>, Martin Storsjo mailto:mar...@martin.st>> Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types. Yes, the MinGW toolchain can handle this by specifying the alignment of a common symbol using the aligncomm directive. The MSVC toolchain has no such mechanism. This is why the check uses isKnownWindowsMSVCEnvironment. On Tue, Jan 8, 2019 at 1:09 PM Shoaib Meenai mailto:smee...@fb.com>> wrote: It checks for both OS=Win32 and Environment=MSVC, so that wouldn't cover other COFF environments. wbs (Martin Storsjo) mentioned on IRC that MinGW adds an aligncomm directive to specify alignment for common symbols, so perhaps that's part of it? From: "Keane, Erich" mailto:erich.ke...@intel.com>> Date: Tuesday, January 8, 2019 at 1:04 PM To: Shoaib Meenai mailto:smee...@fb.com>>, "cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" mailto:cfe-commits@lists.llvm.org>>, David Majnemer mailto:david.majne...@gmail.com>> Subject: RE: r350643 - Limit COFF 'common' emission to <=32 alignment types. Yep, exactly. I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32, which I believe would be different for other architectures. From: Shoaib Meenai [mailto:smee...@fb.com<mailto:smee...@fb.com>] Sent: Tuesday, January 8, 2019 12:41 PM To: Keane, Erich mailto:erich.ke...@intel.com>>; cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>; David Majnemer mailto:david.majne...@gmail.com>> Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types. Ah, looks like you were originally checking for COFF, and then David suggested checking for MSVC instead? I'm curious about why, although I'm sure the suggestion is legit :) From: cfe-commits mailto:cfe-commits-boun...@lists.llvm.org>> on behalf of Shoaib Meenai via cfe-commits mailto:cfe-commits@lists.llvm.org>> Reply-To: Shoaib Meenai mailto:smee...@fb.com>> Date: Tuesday, January 8, 2019 at 12:39 PM To: Erich Keane mailto:erich.ke...@intel.com>>, "cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" mailto:cfe-commits@lists.llvm.org>> Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types. Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the same limitation, since it's an object file format issue and not an ABI issue? From: cfe-commits mailto:cfe-commits-boun...@lists.llvm.org>> on behalf of Erich Keane via cfe-commits mailto:cfe-commits@lists.llvm.org>> Reply-To: Erich Keane mailto:erich.ke...@intel.com>> Date: Tuesday, January 8, 2019 at 10:48 AM To: "cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" mailto:cfe-commits@lists.llvm.org>> Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types. Author: erichkeane Date: Tue Jan 8 10:44:22 2019 New Revision: 350643 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e= Log: Limit COFF 'common' emission to <=32 alignment types. As reported in PR33035, LLVM crashes if given a common object with an alignment of greater than 32 bits. This is because the COFF file format does not support these alignments, so emitting them is broken anyway. This patch changes any global definitions greater than 32 bit alignment to no longer be in 'common'. https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e= Differential Revision: https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDX
Re: [libcxx] r249738 - Split out of .
+Bruno > On Jul 27, 2016, at 11:58 PM, Nico Weber wrote: > > I played with modules a bit today, and as far as I can tell this is still > broken. If this proves difficult to fix, should this change be reverted for > now? It breaks using modules on Darwin. > > On Sun, Mar 13, 2016 at 12:53 AM, Adrian Prantl via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > > On Mar 11, 2016, at 4:11 PM, Duncan P. N. Exon Smith > <mailto:dexonsm...@apple.com>> wrote: > > > > Did anyone file a PR for this? > > > > I filed PR 26928 - Prune the include path for modules > https://llvm.org/bugs/show_bug.cgi?id=26928 > <https://llvm.org/bugs/show_bug.cgi?id=26928> > as a starting point. > > -- adrian > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits> > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged
On 12/2/21 06:45, Nemanja Ivanovic wrote: Hi Tom, would it be OK to directly send you git hashes for patches we would like back ported until the bugzilla transition completes? Yes, that's fine. -Tom On Tue, Nov 30, 2021 at 1:08 AM Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote: Hi, I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. There is still time to submit fixes for the final 13.0.1. I'll give more details about timelines and how to do this once the bugzilla migration is complete. Currently, bugzilla is read-only, so we can't submit any fixes there. -Tom ___ cfe-dev mailing list cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev> ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: r257827 - [CMake] Set SVN_REVISION if CLANG_APPEND_VC_REV=On
This was my bad. The two ifs were meant to be wrapped in if(CLANG_APPEND_VC_REV), I’ve added that in r258143. -Chris > On Jan 18, 2016, at 11:40 AM, Craig Topper wrote: > > CLANG_APPEND_VC_REV doesn't appear to be checked anywhere. Were the two ifs > supposed to check it instead of SVN_VERSION? The way it is now if the first > if body executes, the second if does too since add_version_info_from_vcs sets > SVN_VERSION and thus satisfies the second if. > > On Mon, Jan 18, 2016 at 6:06 AM, Daniel Sanders via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > Thanks, that did the trick. I've removed the workaround from LLVMLinux. > > > -Original Message- > > From: cbiene...@apple.com <mailto:cbiene...@apple.com> > > [mailto:cbiene...@apple.com <mailto:cbiene...@apple.com>] On Behalf Of > > Chris Bieneman > > Sent: 15 January 2016 17:55 > > To: Daniel Sanders > > Cc: cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> > > Subject: Re: r257827 - [CMake] Set SVN_REVISION if > > CLANG_APPEND_VC_REV=On > > > > Thanks for the heads up. It looks like that module is was excluded from the > > LLVM install. I’ve changed that in LLVM r257909. That change should resolve > > your build issue. Please let me know if you continue having problems. > > > > Thanks, > > -Chris > > > > > On Jan 15, 2016, at 5:18 AM, Daniel Sanders > > <mailto:daniel.sand...@imgtec.com>> > > wrote: > > > > > > Hi Chris, > > > > > > This doesn't seem to work when building clang separately from llvm. > > LLVMLinux fails to build clang with: > > > CMake Error at CMakeLists.txt:104 (include): > > > include could not find load file: > > > > > > VersionFromVCS > > > > > > CMake Error at CMakeLists.txt:222 (add_version_info_from_vcs): > > > Unknown CMake command "add_version_info_from_vcs". > > > See > > http://buildbot.llvm.linuxfoundation.org/builders/13_malta/builds/383/step > > <http://buildbot.llvm.linuxfoundation.org/builders/13_malta/builds/383/step> > > s/shell_3/logs/stdio for the full log. > > > > > > I've added a patch to llvmlinux to work around the problem for now > > http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob;f=toolchain/clang/pat > > > > <http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob;f=toolchain/clang/pat> > > ches/clang/workaround- > > versionfromvcsbug.patch;h=848a096df37b1255575650680a266234f5d4936e;h > > b=e0c4c72c5a008006dc230db748ea69e0d1518daf. > > > Should we make that change to clang or fix it another way? > > > > > >> -Original Message- > > >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org > > >> <mailto:cfe-commits-boun...@lists.llvm.org>] On > > Behalf > > >> Of Chris Bieneman via cfe-commits > > >> Sent: 14 January 2016 22:45 > > >> To: cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org> > > >> Subject: r257827 - [CMake] Set SVN_REVISION if > > >> CLANG_APPEND_VC_REV=On > > >> > > >> Author: cbieneman > > >> Date: Thu Jan 14 16:45:12 2016 > > >> New Revision: 257827 > > >> > > >> URL: http://llvm.org/viewvc/llvm-project?rev=257827&view=rev > > >> <http://llvm.org/viewvc/llvm-project?rev=257827&view=rev> > > >> Log: > > >> [CMake] Set SVN_REVISION if CLANG_APPEND_VC_REV=On > > >> > > >> This matches autoconf's ability to put clang revisions in the clang > > >> --version > > >> spew. > > >> > > >> Modified: > > >>cfe/trunk/CMakeLists.txt > > >> > > >> Modified: cfe/trunk/CMakeLists.txt > > >> URL: http://llvm.org/viewvc/llvm- <http://llvm.org/viewvc/llvm-> > > >> > > project/cfe/trunk/CMakeLists.txt?rev=257827&r1=257826&r2=257827&view > > >> =diff > > >> > > == > > >> > > >> --- cfe/trunk/CMakeLists.txt (original) > > >> +++ cfe/trunk/CMakeLists.txt Thu Jan 14 16:45:12 2016 > > >> @@ -101,6 +101,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR > > >> include(AddLLVM) > > >> include(TableGen) > > >> include(HandleLLVMOptions) > > >> + include(VersionFromVCS) > > >>
Re: [libcxx] r278191 - test/hard_link_count(): Fix test on darwin
I'm just curious: Is libcxx generally supposed to merely pass through what the
operating system is returning (as in this case) or is is supposed to provide a
common abstraction that behaves the same on all platforms?
-- adrian
> On Aug 10, 2016, at 8:23 PM, Eric Fiselier via cfe-commits
> wrote:
>
> Thanks Matthias. My apoligies, I lost track of this patch.
>
> On Tue, Aug 9, 2016 at 7:31 PM, Bruno Cardoso Lopes via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Thanks Matthias!
>
> On Tue, Aug 9, 2016 at 6:02 PM, Matthias Braun via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> > Author: matze
> > Date: Tue Aug 9 20:02:28 2016
> > New Revision: 278191
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=278191&view=rev
> > <http://llvm.org/viewvc/llvm-project?rev=278191&view=rev>
> > Log:
> > test/hard_link_count(): Fix test on darwin
> >
> > The hard link count that stat reports are different between normal hfs and
> > the
> > case sensitive variant. Accept both.
> >
> > Modified:
> >
> > libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
> >
> > Modified:
> > libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
> > URL:
> > http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp?rev=278191&r1=278190&r2=278191&view=diff
> >
> > <http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp?rev=278191&r1=278190&r2=278191&view=diff>
> > ==
> > ---
> > libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
> > (original)
> > +++
> > libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
> > Tue Aug 9 20:02:28 2016
> > @@ -45,18 +45,27 @@ TEST_CASE(hard_link_count_for_file)
> >
> > TEST_CASE(hard_link_count_for_directory)
> > {
> > -uintmax_t DirExpect = 3;
> > -uintmax_t Dir3Expect = 2;
> > +uintmax_t DirExpect = 3; // hard link from . .. and Dir2
> > +uintmax_t Dir3Expect = 2; // hard link from . ..
> > +uintmax_t DirExpectAlt = DirExpect;
> > +uintmax_t Dir3ExpectAlt = Dir3Expect;
> > #if defined(__APPLE__)
> > -DirExpect += 2;
> > -Dir3Expect += 1;
> > +// Filesystems formatted with case sensitive hfs+ behave unixish as
> > +// expected. Normal hfs+ filesystems report the number of directory
> > +// entries instead.
> > +DirExpectAlt = 5; // . .. Dir2 file1 file2
> > +Dir3Expect = 3; // . .. file5
> > #endif
> > -TEST_CHECK(hard_link_count(StaticEnv::Dir) == DirExpect);
> > -TEST_CHECK(hard_link_count(StaticEnv::Dir3) == Dir3Expect);
> > +TEST_CHECK(hard_link_count(StaticEnv::Dir) == DirExpect ||
> > + hard_link_count(StaticEnv::Dir) == DirExpectAlt);
> > +TEST_CHECK(hard_link_count(StaticEnv::Dir3) == Dir3Expect ||
> > + hard_link_count(StaticEnv::Dir3) == Dir3ExpectAlt);
> >
> > std::error_code ec;
> > -TEST_CHECK(hard_link_count(StaticEnv::Dir, ec) == DirExpect);
> > -TEST_CHECK(hard_link_count(StaticEnv::Dir3, ec) == Dir3Expect);
> > +TEST_CHECK(hard_link_count(StaticEnv::Dir, ec) == DirExpect ||
> > + hard_link_count(StaticEnv::Dir, ec) == DirExpectAlt);
> > +TEST_CHECK(hard_link_count(StaticEnv::Dir3, ec) == Dir3Expect ||
> > + hard_link_count(StaticEnv::Dir3, ec) == Dir3ExpectAlt);
> > }
> > TEST_CASE(hard_link_count_increments_test)
> > {
> >
> >
> > _______
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>
>
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc <http://www.brunocardoso.cc/>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [lldb-dev] [cfe-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
- Original Message - > From: "Aaron Ballman via cfe-dev" > To: "Chandler Carruth" > Cc: "llvm-dev" , "cfe-dev" , > "openmp-dev > (openmp-...@lists.llvm.org)" , "LLDB" > > Sent: Thursday, June 30, 2016 5:34:13 PM > Subject: Re: [cfe-dev] FYI: Landing the initial draft for an LLVM Code of > Conduct > > Thank you for your continuing efforts on the Code of Conduct! I > appreciate the efforts and strongly support this direction. > > ~Aaron +1 -Hal > > On Thu, Jun 30, 2016 at 2:55 PM, Chandler Carruth via cfe-dev > wrote: > > Hello folks, > > > > As mentioned some time ago[1], we’ve had a long (looong) series > > of > > discussions about establishing a code-of-conduct for the LLVM > > project as a > > whole over on the llvm-dev thread and the > > http://reviews.llvm.org/D13741 > > code review. > > > > The discussion has largely died down for some time, and towards the > > end > > there has been pretty wide support for the draft wording we have > > now. It > > isn’t perfect, and there are still some important questions around > > forming > > the advisory committee to handle reporting, but I think the wording > > is at a > > good point of compromise in a challenging area. > > > > Based on the support, I’m going to land the patch that adds the > > draft. I’m > > hoping this will immediately provide good advice and guidance, and > > I’m > > hoping to see motion on setting up a reasonable advisory committee > > and > > resolving any issues around reporting so we can make this an > > official part > > of the community. > > > > I sending this as a heads up so folks are aware, not to start a new > > discussion thread. There are existing discussion threads[2] on > > llvm-dev if > > folks want to join in active discussion or we can start fresh ones, > > but I > > would encourage people to carefully read the discussion that has > > already > > taken place to avoid revisiting areas that have already been > > heavily > > discussed. > > > > Also, many thanks to the folks who provided all their opinions on > > the > > mailing list threads and in person in long discussions about this > > topic. > > > > Thanks, > > -Chandler > > > > [1]: Prior announcements: > > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > > http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html > > http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html > > http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html > > > > [2]: Existing threads: > > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html > > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html > > > > _______ > > cfe-dev mailing list > > cfe-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
+1. On 06/30/2016 04:01 PM, Hal Finkel via llvm-dev wrote: - Original Message - From: "Aaron Ballman via cfe-dev" To: "Chandler Carruth" Cc: "llvm-dev" , "cfe-dev" , "openmp-dev (openmp-...@lists.llvm.org)" , "LLDB" Sent: Thursday, June 30, 2016 5:34:13 PM Subject: Re: [cfe-dev] FYI: Landing the initial draft for an LLVM Code of Conduct Thank you for your continuing efforts on the Code of Conduct! I appreciate the efforts and strongly support this direction. ~Aaron +1 -Hal On Thu, Jun 30, 2016 at 2:55 PM, Chandler Carruth via cfe-dev wrote: Hello folks, As mentioned some time ago[1], we’ve had a long (looong) series of discussions about establishing a code-of-conduct for the LLVM project as a whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 code review. The discussion has largely died down for some time, and towards the end there has been pretty wide support for the draft wording we have now. It isn’t perfect, and there are still some important questions around forming the advisory committee to handle reporting, but I think the wording is at a good point of compromise in a challenging area. Based on the support, I’m going to land the patch that adds the draft. I’m hoping this will immediately provide good advice and guidance, and I’m hoping to see motion on setting up a reasonable advisory committee and resolving any issues around reporting so we can make this an official part of the community. I sending this as a heads up so folks are aware, not to start a new discussion thread. There are existing discussion threads[2] on llvm-dev if folks want to join in active discussion or we can start fresh ones, but I would encourage people to carefully read the discussion that has already taken place to avoid revisiting areas that have already been heavily discussed. Also, many thanks to the folks who provided all their opinions on the mailing list threads and in person in long discussions about this topic. Thanks, -Chandler [1]: Prior announcements: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html [2]: Existing threads: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html ___ cfe-dev mailing list cfe-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ cfe-dev mailing list cfe-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev _______ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[libcxx] r312260 - [libcxx] [www] Manually change http links to https.
Author: stl_msft Date: Thu Aug 31 10:59:42 2017 New Revision: 312260 URL: http://llvm.org/viewvc/llvm-project?rev=312260&view=rev Log: [libcxx] [www] Manually change http links to https. Fixes D37318. Modified: libcxx/trunk/www/atomic_design.html libcxx/trunk/www/atomic_design_a.html libcxx/trunk/www/atomic_design_b.html libcxx/trunk/www/atomic_design_c.html libcxx/trunk/www/cxx1y_status.html libcxx/trunk/www/cxx1z_status.html libcxx/trunk/www/cxx2a_status.html libcxx/trunk/www/index.html libcxx/trunk/www/ts1z_status.html libcxx/trunk/www/type_traits_design.html libcxx/trunk/www/upcoming_meeting.html Modified: libcxx/trunk/www/atomic_design.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design.html (original) +++ libcxx/trunk/www/atomic_design.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN +https://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC Modified: libcxx/trunk/www/atomic_design_a.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_a.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design_a.html (original) +++ libcxx/trunk/www/atomic_design_a.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN +https://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC Modified: libcxx/trunk/www/atomic_design_b.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_b.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design_b.html (original) +++ libcxx/trunk/www/atomic_design_b.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN +https://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC Modified: libcxx/trunk/www/atomic_design_c.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_c.html?rev=312260&r1=312259&r2=312260&view=diff ====== --- libcxx/trunk/www/atomic_design_c.html (original) +++ libcxx/trunk/www/atomic_design_c.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.or
Re: [Lldb-commits] [lldb] r283351 - Try to fix Android build.
I don't know if that's the problem here, but part of the problem comes from
the fact that android uses it's own standard c library, which does some
things slightly differently. Also, the c++ library is somewhat customized.
On 5 October 2016 at 11:18, Tamas Berghammer via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> It is using "gcc version 4.9 20150123 (prerelease) (GCC)"
>
> On Wed, Oct 5, 2016 at 11:12 AM Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> I don't know for sure, but I'm guessing it's using GCC, and perhaps even
>> an old one at that.
>>
>> On Wed, Oct 5, 2016 at 11:10 AM Enrico Granata
>> wrote:
>>
>> Alright, I'll bite and ask...
>>
>> What is so special about the Android bot? Every so often, I'll see it
>> reject a piece of syntax that other compilers gleefully handle
>>
>> On Oct 5, 2016, at 10:58 AM, Zachary Turner via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>> Author: zturner
>> Date: Wed Oct 5 12:58:46 2016
>> New Revision: 283351
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=283351&view=rev
>> Log:
>> Try to fix Android build.
>>
>> Seems it doesn't like the implicit conversion from
>> StringRef[] to ArrayRef.
>>
>> Modified:
>>lldb/trunk/source/Breakpoint/BreakpointID.cpp
>>
>> Modified: lldb/trunk/source/Breakpoint/BreakpointID.cpp
>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/
>> Breakpoint/BreakpointID.cpp?rev=283351&r1=283350&r2=283351&view=diff
>>
>> ==
>> --- lldb/trunk/source/Breakpoint/BreakpointID.cpp (original)
>> +++ lldb/trunk/source/Breakpoint/BreakpointID.cpp Wed Oct 5 12:58:46
>> 2016
>> @@ -48,7 +48,7 @@ bool BreakpointID::IsValidIDExpression(l
>> }
>>
>> llvm::ArrayRef BreakpointID::GetRangeSpecifiers() {
>> - return g_range_specifiers;
>> + return llvm::makeArrayRef(g_range_specifiers);
>> }
>>
>> void BreakpointID::GetDescription(Stream *s, lldb::DescriptionLevel
>> level) {
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [PATCH] trivial documentation fix regarding Obj-C ARC objc_arc_weak_reference_unavailable
On 9/2/16 9:26 AM, Sean McBride via cfe-commits wrote: Friendly ping... this is a very trivial documentation patch... LGTM On Wed, 10 Aug 2016 13:57:07 -0400, Sean McBride via cfe-commits said: Fixed incorrect docs that referred to: objc_arc_weak_unavailable when it should be: objc_arc_weak_reference_unavailable Cheers, Sean ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits -- Jon Roelofs jonat...@codesourcery.com CodeSourcery / Mentor Embedded ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: Allow tools to work without compilation database
-if (!Compilations)
- llvm::report_fatal_error(ErrorMessage);
+if (!Compilations) {
+ errs() << "Compilation database not found - using default options\n";
+ int argc = 1;
+ const char *argv[] = {"--"};
+ Compilations.reset(
+ FixedCompilationDatabase::loadFromCommandLine(argc, argv));
Just Compilations.reset(new FixedCompilationDatabase(".",
std::vector()))?
On Thu, Dec 3, 2015 at 8:51 AM Russell Wallace via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Per discussion at
> http://lists.llvm.org/pipermail/cfe-dev/2015-December/046321.html allow
> tools to work in the absence of a compilation database, but warn the user
> about the absence.
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [Lldb-commits] Use explicit delete in DISALLOW_COPY_AND_ASSIGN
Not sure why operator= is returning a const&. It doesn't matter in practice but it's a bit strange. Anyway lgtm On Tue, Sep 27, 2016 at 7:11 PM Daniel Austin Noland via lldb-commits < lldb-commits@lists.llvm.org> wrote: > Explicit delete is preferable to declaring a method private when > your intention is to prevent that method from ever being used. > > * better compiler error messages > * can't be bypassed by friendship > * clearer intent > > This was discussed here: > http://lists.llvm.org/pipermail/lldb-dev/2016-September/011394.html > > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [lldb-dev] Moderator needed for lldb-commits
Hi Tanya, I'm also in! - Raphael Am Mo., 9. Juli 2018 um 13:50 Uhr schrieb Jonas Devlieghere via lldb-dev : > > Hi Tanya, > > I'd be happy to take care of this! > > Cheers, > Jonas > > > On Jul 6, 2018, at 6:01 PM, Tanya Lattner via lldb-dev > > wrote: > > > > LLDB Developers, > > > > Moderators are needed for the lldb-commits mailing list. Is anyone > > interested in helping out? > > > > Thanks, > > Tanya > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs
Great! I think we should proceed with your is_trivially_copyable idea and I'll see if I can come up with a pathological test case that breaks it. Hopefully we can find something that works. On Mar 17, 2016 2:54 PM, "Duncan P. N. Exon Smith via cfe-commits" < cfe-commits@lists.llvm.org> wrote: > r263746. > > > On 2016-Mar-17, at 13:36, Duncan P. N. Exon Smith via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > > >> > >> On 2016-Mar-16, at 15:41, Eric Fiselier wrote: > >> > >> EricWF accepted this revision. > >> EricWF added a comment. > >> This revision is now accepted and ready to land. > >> > >> LGTM after change in inline comment. > >> > >> > >> > >> Comment at: include/__hash_table:114 > >> @@ +113,3 @@ > >> +template > >> +struct __can_extract_key<_Pair, _Key, pair<_First, _Second>> > >> +: conditional::type, > _Key>::value, > >> > >> `>>` needs to be `> >` for C++03. > > > > Since __can_extract_key is only used when !defined(_LIBCPP_CXX03_LANG), > > I'll just move it behind an #ifdef (and leave the prettier `>>`). > > > > I'll commit after running the tests with -std=c++03. > > > >> > >> http://reviews.llvm.org/D16360 > >> > >> > >> > > > > ___ > > cfe-commits mailing list > > cfe-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
