CALL FOR PAPERS / PARTICIPATION
At FOSDEM 2016, LLVM will for the first time participate with a
dedicated devroom. Complementing the upcoming Euro LLVM 2015, the
devroom at FOSDEM provides a great opportunity for core LLVM developers
and the wider open source community to get together, connect and
Gentle reminder, the deadline is approaching.
On 2 November 2015 at 13:32, Renato Golin wrote:
> CALL FOR PAPERS / PARTICIPATION
>
> At FOSDEM 2016, LLVM will for the first time participate with a
> dedicated devroom. Complementing the upcoming Euro LLVM 2015, the
> devroom at FOSDEM provides a g
Good news, folks!
Following FOSDEM's own delay on their schedule, we'll extend the
deadline until next Friday, 11th December.
cheers,
--renato
On 2 November 2015 at 13:32, Renato Golin wrote:
> CALL FOR PAPERS / PARTICIPATION
>
> At FOSDEM 2016, LLVM will for the first time participate with a
Sounds good.
On 11 December 2015 at 23:14, Hans Wennborg wrote:
> Dear everyone,
>
> It's not quite time to start the 3.8 release process, but it's time to
> start planning.
>
> Please let me know if you want to help with testing and building
> release binaries for your favourite platform. (If yo
Hans, Daniel,
How are things going? It's been 5 days and no word. I'm running the
tests now, just in case, but would be good to know that no one would
be committing to the release candidate 1 tree in the mean time.
cheers,
--renato
On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev
wrote:
On 20 January 2016 at 17:49, Hans Wennborg wrote:
> Did you send this before I sent the rc1 email, or what things are you
> referring to? :-)
Damn it, my filter isn't working as well as I expected! :) Sorry about
the noise.
--renato
___
lldb-dev mailin
ARM and AArch64 seem both good. Uploaded.
On 19 January 2016 at 23:47, Hans Wennborg wrote:
> Dear testers,
>
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge r
On 20 January 2016 at 09:31, Sylvestre Ledru wrote:
> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)
I second that! It'd also be much easier on mail filters... :)
--renato
___
lldb-dev maili
On 2 February 2016 at 21:15, Hans Wennborg via lldb-dev
wrote:
> Dear testers,
>
> Release Candidate 2 has just been tagged [1]. Please build, test, and
> upload to the sftp.
ARM and AArch64 look good, uploaded. I'm not using any new distro, so
all the ABI issues are not showing, but they do exi
Hi folks,
FOSDEM was a great success, with the room packed most of the time and
some great talks.
The slides were uploaded to the web page
(http://llvm.org/devmtg/2016-01/) but the videos unfortunately
couldn't be used (they had no audio). Due to the voluntary nature of
FOSDEM, these things can a
On 6 February 2016 at 01:02, C Bergström wrote:
> I worked on the port of llvm-OpenMP-formally-known-as-Intel to Aarch64
> - can it be included there as well? (I'm not sure what's precisely
> involved - I'm willing to do my best fixing any bugs which pop up -
Hi Chris,
That'd entail me enabling
On 8 February 2016 at 22:56, wrote:
> Imho it's critical to get parallel programming working on ARMv8 ( even if
> it's crappy OMP) to start. Please enable it and I'll run the tests against
> our internal QA and we can informally handle testing / guarding against
> regressions.
Ok, I'll do it
On 19 February 2016 at 00:22, Hans Wennborg via lldb-dev
wrote:
> - PR26600: Loop vectorization creates an unsafe out-of-bounds load
> There's a patch out: http://reviews.llvm.org/D17332
> But no comments yet.. Hal?
This looks like a serious bug but Hal's idea is still unproven. I
think we sh
On 19 February 2016 at 15:33, Renato Golin wrote:
> On 19 February 2016 at 00:22, Hans Wennborg via lldb-dev
> wrote:
>> - PR26600: Loop vectorization creates an unsafe out-of-bounds load
>> There's a patch out: http://reviews.llvm.org/D17332
>> But no comments yet.. Hal?
>
> This looks like
On 8 February 2016 at 23:14, Hans Wennborg wrote:
> Sounds good to me, but if it doesn't build, or there are other
> problems, I won't treat them as blocking 3.8.
Absolutely! Experimental quality. :)
--renato
___
lldb-dev mailing list
lldb-dev@lists.ll
On 8 February 2016 at 22:56, wrote:
> Imho it's critical to get parallel programming working on ARMv8 ( even if
> it's crappy OMP) to start. Please enable it and I'll run the tests against
> our internal QA and we can informally handle testing / guarding against
> regressions.
So, I got some
On 23 February 2016 at 21:51, Hans Wennborg via cfe-dev
wrote:
> Dear testers,
>
> Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.
Uploaded and tested for ARM and AArch64, all good.
Remember, this is *not* using a new Linux, so the GCC 5 issue doesn't
Apologies for the delay, ARM and AArch64 tested and uploaded!
--renato
On 3 March 2016 at 07:33, Hans Wennborg via lldb-dev
wrote:
> Dear testers,
>
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>
> Please b
Folks,
There has been some discussion on IRC about SVN hosting and the perils
of doing it ourselves. The consensus on the current discussion was
that moving to a Git-only solution would have some disvantages, but
many advantages. Furthermore, not hosting our own repos would save us
a lot of headac
On 31 May 2016 at 21:24, Aaron Ballman wrote:
> Are we sure that github's svn integration works with common tools on
> Windows, like TortoiseSVN?
That's a good question. Can you try them out and report back?
cheers,
--renato
___
lldb-dev mailing list
l
On 31 May 2016 at 21:28, Mehdi Amini wrote:
> Ideally, I'd prefer the cross-repository to be handled with an extra layer,
> in a way similar as described in:
> https://gerrit-review.googlesource.com/Documentation/user-submodules.htm
> (somehow conceptually similar to Android manifests XML files
On 1 June 2016 at 05:16, Douglas Gregor wrote:
> Performance can also be an issue; it takes a bunch of fast bots to keep up
> with developers testing their pull requests, especially when what you’re
> testing is a very large C++ code base. That said, “test and merge on success”
> workflows are
On 1 June 2016 at 18:12, Dan Liew wrote:
>> So clone llvm ; cd tools / ; clone ...
>> --
>> good luck with this.. I foresee near religious opinions on the horizon..
>
> As do I.
Isn't that solved by the llvm-projects repository format?
--renato
___
On 1 June 2016 at 17:02, John Criswell wrote:
> Do you have a set of volunteers lined up to do such a migration? Getting
> people willing to do the migration will obviously be key, and that was the
> one thing I didn't see in the original email.
Hi John,
Well, first we need to know if people are
On 1 June 2016 at 19:31, Mehdi Amini wrote:
> If you move to git-only without the rest of the infrastructure/scripts, we're
> losing the convenience we have today with svn, and the "user experience" will
> not be so great. We may face resistance to this change.
> I advocate to first set it up ti
On 1 June 2016 at 19:36, Aaron Ballman wrote:
> Despite people's reservations of a git-only repository?
Hi Aaron, not at all!
I was especially vague on my first email to make sure SVN folks would
be shoved on the side, but John had asked for a full plan *in the case
we move*, and I was just comp
On 1 June 2016 at 19:55, Mehdi Amini wrote:
> 12.2: mirror git to svn :)
either that or use GitHub's SVN interface, which is RW.
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
On 1 June 2016 at 20:31, Aaron Ballman wrote:
> Our main repo is in SVN; I would say we don't know what most people
> are using (aside from "svn for write access because it's the only
> option").
If the LLVM Meetings are any indication, and they are at least related
to the most active developers,
On 1 June 2016 at 21:21, Mehdi Amini wrote:
> I'm not sure how to be robust against that other than putting all the
> projects in the same repo and asking developers to build them all before push.
I'm strongly against a single repo with all in, or asking to build
LLDB when the commit is in Compi
I think we should start two other threads: one about git tooling on Windows
and one about infrastructure problems migrating to git.
I'm confident we can solve both problems relatively easily.
Cheers,
Renato
On 1 Jun 2016 10:09 p.m., "Aaron Ballman" wrote:
> On Wed, Jun 1, 2016 at 3:25 PM, James
On 2 June 2016 at 13:43, Aaron Ballman via lldb-dev
wrote:
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has some integration, but I've not
> used it before. Perhaps other tools exist that match the integration
> and stability that TortoiseSVN
A little summary...
After a lot of discussion, I think we converged to a few issues that
we need to solved before we finally decide to move.
Firstly, the responses were overwhelmingly positive (I counted 20 of
the ~25 people strongly supporting and another 2~3 weakly supporting).
This is a good i
On 3 June 2016 at 06:39, Jeremy Lakeman wrote:
> For example;
> write a new feature as a series of patches against both llvm & clang
> open a pull request
> somebody pushes some "approval" button (in Phabricator?)
> both patch series are rebased onto llvm & clang's TOT
> a single commit is created
On 12 June 2016 at 13:27, Dimitry Andric via llvm-dev
wrote:
>> 1) Right after the branch, the version number of the trunk will be
>> incremented. I assume this means bumping the major version number,
>> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
>
> 4.0. Since gcc is already
On 13 June 2016 at 14:23, David Chisnall via lldb-dev
wrote:
> I don’t think that this makes it simple for anyone. Existing packaging tools
> understand dot notation and know that 3.10 > 3.9, even if interpreting the
> dot as a decimal point would mean that it didn’t. Without this kind of
> s
On 13 June 2016 at 17:24, Robinson, Paul via cfe-dev
wrote:
> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.
There isn't one. Never was.
On 13 June 2016 at 18:02, Rafael Espíndola wrote:
> It is documented at
>
> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
This is weird...
"The bitcode format produced by a X.Y release will be readable by all
following X.Z releases and the (X+1).0 release."
Why (x+1).0 ?
On 13 June 2016 at 18:30, Michael Kuperstein wrote:
> It would probably better for whoever wrote this text to pipe in, but I think
> the idea is that (X+1).0 is supposed to be a kind of a "bridge" release.
That rings a bell... but I have to be honest, it's weird...
Now, well, as Rafael said orig
So,
It's been a while and the GitHub thread is officially dead, so I'll
propose a development methodology based on the feedback from that
thread. This is not *my* view, but all that was discussed in the
threads.
My objective is to form an official proposal to use Git as our main
repository, overc
On 26 June 2016 at 23:02, Anton Korobeynikov wrote:
> Does github allow this? IIRC their support for server-side hooks was
> very limited due to obvious reasons. And executing hooks e.g. on
> llvm.org seems very error-prone.
Someone suggested it was possible. I have sent them an email with a
draf
On 27 June 2016 at 01:20, Matthias Braun wrote:
> I really liked the the solution proposed earlier in this thread: Do nothing
> server side, but instead use
> `git rev-list --count master` on the client side (which takes 0.9s on my
> machine) to get the number of the commit. So nothing to do on
On 27 June 2016 at 15:39, Rafael Espíndola wrote:
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to
I don't think the consensus was to change
On 27 June 2016 at 17:03, Rafael Espíndola wrote:
> I think that trying to create a ordering/rev number between independent git
> repositories is fundamentally unreliable.
>
> If we want to keep llvm and clang in lock step we should probably probably
> just have them in the same repository like
>
On 28 June 2016 at 06:55, NAKAMURA Takumi wrote:
> It has also submodules.
> https://github.com/llvm-project/llvm-project-submodule
>
> Both llvm-project(-tree) and (-submodule) have refs/notes/commits.
Nice! Can you try a server hook that will add an auto-increment number
from submodules commits
On 28 June 2016 at 17:33, Tim Northover wrote:
> I really like this too, and think Takumi has basically solved 90% of
> the problem for us already. We may want to add an "rN" line to avoid
> scaring people with hex commits, but that seems to be all that's
> lacking and not really essential anyway.
On 28 June 2016 at 16:46, Mehdi Amini wrote:
> Why? Assuming we don’t have branches, there was many mention that the id can
> be computed from the number of commits in the history.
We have branches (release_nm) and we may want them to be in the same
sequential numbering.
So, I'm assuming this h
Hi all,
A short summary: Takumi has done 90% of the work here:
https://github.com/llvm-project/llvm-project-submodule
and I've been talking to GitHub, and here are the answers to my questions:
> 1. How will the umbrella project's auto-increment hook work?
Since the umbrella project cannot see
On 29 June 2016 at 15:11, David Chisnall wrote:
> Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub
> continue to work by simply switching the remote in the config?
I hope so. There isn't anything (modulo mistakes) stopping us from
having a clean migration.
We'll have
On 29 June 2016 at 16:50, Tom Honermann wrote:
> How would you coordinate dependent updates to the sub-modules?
We won't. Not now. Maybe later.
Right now, doing that means changing how we work and we're trying to
make the least number of changes at a time.
But this is the most requested feature
On 29 June 2016 at 19:51, Sean Silva wrote:
> Roughly speaking, I would prefer a repo division (if any) to be along the
> lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff
> not strictly required".
The problem comes when different people consider "core" different projects
On 29 June 2016 at 20:14, Sean Silva wrote:
> Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
> important special case we may be able to agree on. (and I say this as
> somebody that largely builds cross-compilers (targeting PS4))
In that case, RT wouldn't "have" to be cor
On 30 June 2016 at 05:14, Tim Northover wrote:
>> That makes it fragile, and that’s why I disagree with your “90% done”
>> assessment.
>> What if the service behing the hook is down for a few days?
>
> In the long-term view, a pretty trivial catch-up script ought to be
> able to synthesize a sane
Now that we seem to be converging to an acceptable Git model, there
was only one remaining doubt, and that's how the trigger to update a
sequential ID will work. I've been in contact with GitHub folks, and
this is in line with their suggestions...
Given the nature of our project's repository struc
On 30 June 2016 at 17:33, Reid Kleckner wrote:
> Agreed, the llvm-project repository can completely take on the role of the
> SQL database in Renato's proposal.
Hum, doing it in a separate server was suggested by the GitHub folks,
so I just assumed they can't do that in the umbrella project for s
On 30 June 2016 at 16:23, Frédéric Riss wrote:
>> The only thing we *have* to have a sequential number for, are
>> releases. Even that can be ran manually.
>
> LNT and ‘llvmlab bisect’ also currently rely heavily on having sequential
> numbers as commit identifiers.
One of the steps of the migra
I guess the point is that, for some, not having that clause, causes
discomfort and reduce their contribution. For others, having that clause
causes discomfort and reduce their contribution.
I don't think one is more important than the other, nor I think we should
see this as which side makes more
On 30 Jun 2016 10:20 p.m., "Robinson, Paul" wrote:
> We've since stopped creating the tags, and gotten used to not having
> them. We do the 'rev-list --count' trick which mainly gets recorded as
> one component of the version number, and it has been working for us.
Does that work for sub modules
On 1 July 2016 at 18:32, Daniel Berlin via lldb-dev
wrote:
>> The single word "rare" in the current code doesn't feel like enough.
>
> I don't actually disagree with your criticism, IMHO, i just don't know of a
> way to generate more clarity.
Paul, Rafael, Daniel,
With the intention of being pra
On 1 July 2016 at 17:32, Tim Northover wrote:
> My issue with using tags like this is that they pollute the tag
> namespace and will quickly swamp what I consider to be the important
> ones ("release-X"). OK, so we've got "git tag -l 'release*'" but
> that's pretty ugly.
What if we had a mixed mo
On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev
wrote:
> "git-describe -t" works also for lw tags.
But it doesn't work if there are no tags, I just tested on LLVM and I get:
$ git describe
fatal: No names found, cannot describe anything.
Should be easy enough to create the tags on each br
On 4 July 2016 at 00:42, Robinson, Paul wrote:
> Daniel claimed it was not different, even though he proposed the text.
> I think it is better, as "egregious" (even though it is qualitative)
> helps identify what "rare" circumstances would come under the policy.
> As a non-lawyer I do think it's d
On 4 July 2016 at 15:21, Bruce Hoult wrote:
> What doesn't scale about tagging every commit?
Both Jim and Takumi have reported problems with thousands of tags.
Even though neither of them responded to your enquiries for additional
data, we can't assume there isn't any.
Furthermore, "git describe
Quick re-cap.
After a few rounds, not only the "external server" proposal got
obliterated as totally unnecessary, but the idea that we may even need
a hook at all is now challenged.
Jared's idea to use "git describe" is in line with previous proposals
to use rev-list --count and to do so only up
On 5 July 2016 at 12:13, David Chisnall wrote:
> Note that GitHub (currently, at least) doesn’t export submodules sensibly
> with their svn version.
SVN users can continue using the projects directly, they *just* need
to change the SVN repository location of every project to GitHub.
It can't ge
On 5 Jul 2016 10:45 p.m., "Mehdi Amini" wrote:
>
>
> > On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> >
> > Quick re-cap.
> >
> > After a few rounds, not only the "external server" proposal got
> > obliterated as totally unnecessary, but the idea that we
On 8 July 2016 at 01:56, Chris Matthews wrote:
> With both llvmlab and LNT, once you get to a range of IDs, it is needs to be
> easy to find out what commits or commit range those IDs map to. When given
> regression between 123 and 225, I need the list of commits, and I don’t want
> to log grep f
On 8 July 2016 at 03:14, Robinson, Paul wrote:
> I could see wanting to compare data from master and a release branch. If
> that means sequential IDs need to work across branches, then we're back to
> needing a fancier solution than 'rev-list –count'.
How would you do this in SVN anyway?
Branch
On 8 July 2016 at 17:45, Mehdi Amini wrote:
> You missed the point that in a single instance of LNT a revision number has
> to be unique.
> The rev-list thing won't provide this across branches.
> A rev-list count number won't identify a revision, you need the tuple
> (branch, count), which is l
On 8 July 2016 at 21:04, Mehdi Amini wrote:
>> What about git describe?
>
> Not a number.
It contains a number... "tag-number-hash"
Removing the tag and hash seems trivial.
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.o
On 8 July 2016 at 21:07, Mehdi Amini wrote:
> The problem is not that is it is not possible to work with a tuple (branch,
> number), the problem is that a tuple (or a string) is not a number and breaks
> existing infrastructure. It does not mean it cannot be made to work, but it
> won’t out-of-
On 8 July 2016 at 20:12, Chris Matthews wrote:
> If LNT is the only holdout I suggest we update the LNT model to natively
> handle git.
I could say the reverse... If improving LNT is a reason to move to
Git, than we should do it. :)
> This sort of change to the
> guts of how LNT works is weeks
On 29 July 2016 at 23:57, Hans Wennborg via Release-testers
wrote:
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
First wave of testing pass on ARM. Uploaded to the FTP server.
Is it time to do the back-ports planned? I only
On 1 August 2016 at 17:37, Hans Wennborg wrote:
>> Is it time to do the back-ports planned? I only have a very minor bug fix.
>
> Sure!
Backported the v6T2/DSP patch. Now just needs to get Diana's AArch64
fix and we're fine.
cheers,
--renato
___
lldb-d
On 2 August 2016 at 16:17, Hans Wennborg wrote:
> Looks like Diana's fix was merged in r277462, so it sounds like we're all
> good.
Yup, we're good.
Thanks!
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
On 3 August 2016 at 00:46, Hans Wennborg wrote:
> - Dmitry, Renato: the Clang notes mention abi_tag. Do we want to
> expand the text here a little? Link to the PR?
We certainly do. This is a big deal. I'll write up something and let
Dmitry correct my mistakes. :)
We'll also add the ARM/AArch64 c
On 3 August 2016 at 10:46, Renato Golin wrote:
> We certainly do. This is a big deal. I'll write up something and let
> Dmitry correct my mistakes. :)
Done.
> We'll also add the ARM/AArch64 changelogs.
Done. :)
cheers,
--renato
___
lldb-dev mailing
On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev
wrote:
> Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and
> higher, due to a conflict of initialization order with our jemalloc. So I am
> not extremely keen on fixing this before the release.
This sounds really s
On 4 August 2016 at 19:17, Hans Wennborg via Release-testers
wrote:
> Source and binaries for LLVM-3.9.0-rc1 are now available at
> http://llvm.org/pre-releases/3.9.0/#rc1
Ouch! I forgot to upload the AArch64 image! Sorry, it's there now.
cheers,
--renato
On 19 August 2016 at 02:51, Hans Wennborg via Release-testers
wrote:
> This is a release candidate in the very real sense that if nothing new
> comes up, this is be what the final release looks like. There are
> currently no open release blockers, and no patches in my merge-queue.
ARM binaries go
Hi Hans,
I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the
wrong one?
Cheers,
Renato
On 22 Aug 2016 7:55 p.m., "Hans Wennborg via Release-testers" <
release-test...@lists.llvm.org> wrote:
> We're getting close to the final release. I know the schedule on the
> web page s
On 25 August 2016 at 04:42, Hans Wennborg via Release-testers
wrote:
> Dear testers,
>
> 3.9.0-rc3 was just tagged from the branch at r279704.
ARM and AArch64 seem fine, binaries uploaded:
ARM sha1sum: d1bc90d475f8d764f1ff7524ba2f3e26acb8a463
AArch64 sha1sum: 5e4e3bdf747aa2ac50c588cea5d67f896376
ARM and AArch64 green, uploaded. Thanks!
$ sha1sum clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz
e9bfdf32c869e8fb344ef1b386c5d2b44ccac056
$ sha1sum clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz
2ad7a7b226b78d5c13ef06abb96da7a0fb8d535e
--renato
On 2 September 2016 at 01:38, Ben Pope via cfe-dev
wr
On 26 September 2016 at 19:12, Anton Korobeynikov via llvm-dev
wrote:
> Note that nothing was decided yet, it might be very probable that
> we'll continue use Bugzilla, we're just evaluating other options and
> collecting the relevant information. We will try to make sure that
> there will be no m
CALL FOR PAPERS / PARTICIPATION
At FOSDEM 2017, LLVM will again participate with a dedicated devroom.
Complementing the upcoming Euro LLVM 2017, the devroom at FOSDEM
provides a great opportunity for LLVM developers and the wider open
source community to get together, connect and discuss.
As poss
Folks,
After a number of months in preparation and just two weeks away from
the US Dev. Meeting, where we'll hold a BoF to discuss the Git
migration, here's how you'll voice your concerns:
https://goo.gl/forms/ZYs0Wv9g0w0ikCRQ2
The survey is meant to be a channel for people and
companies/project
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
On 2 November 2016 at 13:43, Zachary Turner 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.
Corrected. Please chec
Folks,
It's been one week after the initial results were shared and three
days after the last answer, so I think it's time to close down and
publish the final results.
The ODF, XLS and CSV files are at:
http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip
The overall result is t
Gentle reminder, the deadline is tomorrow, but we may extend to the
end of the week.
Keep your proposals coming. Thanks!
cheers,
-renato
On 11 October 2016 at 14:25, Renato Golin wrote:
> CALL FOR PAPERS / PARTICIPATION
>
> At FOSDEM 2017, LLVM will again participate with a dedicated devroom.
>
On 5 December 2016 at 18:26, Hans Wennborg via Release-testers
wrote:
> I propose the following schedule for the 4.0 release:
>
> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>
> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>
> - 21 February: Final
On 5 December 2016 at 18:42, Dimitry Andric via Release-testers
wrote:
> Maybe I didn't pay enough attention, but where is the general outline
> for this versioning scheme documented? And are we still going to do
> 4.1, 4.2, etc?
This is the thread:
http://lists.llvm.org/pipermail/llvm-dev/2016
On 5 December 2016 at 18:56, Hans Wennborg via Release-testers
wrote:
> The idea is that Tom's stable releases will keep incrementing the
> "patch" part of the version numbers, just as today, so they would be
> 4.0.1, 4.0.2, etc.
Hum, this looks weird. I was under the impression that we'd do 4.1,
On 5 December 2016 at 19:08, Michał Górny via cfe-dev
wrote:
> Will this new version scheme mean that 4.1 (if ever released) will be
> ABI-compatible with 4.0? If it will be so, we should update SONAMEs
> accordingly.
Yes. All 4.x will be ABI compatible with 4.0, just like any stable
release we d
On 5 December 2016 at 19:56, Hans Wennborg wrote:
> I'd like to avoid 4.1 because of the potential for confusion about
> whether it's a major release (as it would have been under the old
> scheme) or a patch release.
But if the versioning scheme is different, users will have to
understand what it
On 5 December 2016 at 20:07, Hans Wennborg wrote:
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/
IMO, this is too small of a worry to encumber us for the rest of our
release days with silly zeroes.
I'd rather be redunda
On 19 January 2017 at 17:43, Diana Picus via Release-testers
wrote:
> Looks good on AArch64:
> c6cc242dc3551c8465ba054e87e4d51df824aa17
> clang+llvm-4.0.0-rc1-aarch64-linux-gnu.tar.xz
All good on ARM's side, too:
38e34694bb2ddd5178f48c2bef0aef65cc17b378
clang+llvm-4.0.0-rc1-armv7a-linux-gnueabih
Hi folks,
All FOSDEM 2017 LLVM Devroom's videos are online:
https://fosdem.org/2017/schedule/track/llvm_toolchain/
Some slides are still missing, but we hope to get them soon enough.
The videos have the slides on split screen.
cheers,
--renato
___
lld
On 9 February 2017 at 17:55, Diana Picus via llvm-dev
wrote:
> Hi,
>
> AArch64 good to go.
>
> f27db27da7f75a435d89ba63c8a762885fd86a1a
> clang+llvm-4.0.0-rc2-aarch64-linux-gnu.tar.xz
No regressions from the ARM side.
f827daf4b0066f74932090cb6309fcf6be594617
clang+llvm-4.0.0-rc2-armv7a-linux-gnu
On 10 February 2017 at 11:38, Pavel Labath via llvm-dev
wrote:
> All I can say is these tests did not exist in 3.9, so I wouldn't call
> this a regression. (Well... technically, a similar test existed, but
> it was run by a different test runner which I believe is not hooked up
> to the command yo
On 10 February 2017 at 22:23, Hans Wennborg wrote:
> A reasonable thing to do would be to put a note on the relaese
> downloads page. But I'm not even sure what to put there. "OpenMP kind
> of works on AArch64", what does that mean to a user?
The idea was to just separate in two classes: support
1 - 100 of 129 matches
Mail list logo
