[llvm-dev] [cfe-dev] Your help needed: List of LLVM Open Projects 2017

Anton Korobeynikov via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 16 13:14:47 PST 2017

Please submit patches to Open Projects pages! Winter^WSummer of Code is coming!

On Mon, Jan 16, 2017 at 1:13 PM, Piotr Padlewski via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The list can't ommit clang-tidy.
> There are many ideas about new checks on llvm bugzilla.
> https://llvm.org/bugs/buglist.cgi?product=clang-tools-extra&component=clang-tidy&resolution=---&list_id=110936
> Everything matching ".*Feature Request.*"
> Piotr
> 2017-01-16 21:31 GMT+01:00 Sean Silva via cfe-dev <cfe-dev at lists.llvm.org>:
>> Do we have any open projects on LLD?
>> I know we usually try to avoid any big "projects" and mainly add/fix
>> things in response to user needs, but just wondering if somebody has any
>> ideas.
>> Some really generic/simple stuff I can think of:
>> 1. trying out LLD on a large program corpus and reporting/reducing/fixing
>> bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
>> packages from a linux distro like Debian or Gentoo)
>> 2. performance analysis and optimization of LLD
>> 3. getting LLD to link a bootable Linux kernel and/or GRUB
>> 4. write an input verifier such that LLD can survive intensive fuzzing
>> with no crashes / fatal errors [1] when the verifier says the input is okay.
>> This will allow us to measure what the overhead of doing this actually is.
>> [1] As of the latest LLD discussion (in the thread "[llvm-dev] LLD status
>> update and performance chart") it sounds like people are okay with LLD
>> treating fatal errors the same way that LLVM uses assertions; for inputs
>> from the C++ API, we can document to not pass corrupted object files. For
>> inputs read from files, there is still community interest in at least having
>> the option to run a "verifier" to validate the inputs. I think the best way
>> to approach the verifier is to essentially follow the approach suggested by
>> Peter (in the context of "hardening") in
>> https://llvm.org/bugs/show_bug.cgi?id=30540#c5 i.e. getting to the point
>> where LLD can survive intensive fuzzing.
>> -- Sean Silva
>> On Mon, Jan 16, 2017 at 5:18 AM, Vassil Vassilev via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> Hi folks,
>>>   Happy new year!
>>>   Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation
>>> LLVM Developers'. It was suggested that we should update our open projects
>>> page and possibly restructure it a little bit.
>>>   I volunteered to do this work and I need your help.
>>>   Chandler and I started working on a google doc [1]. We pinged few code
>>> owners asking them to list of work items we should get done in 2017 but we
>>> do not have the manpower. Now we would like to ask for your input, too.
>>>   I believe an up to date list can serve as a good entry point for
>>> students, interns and new contributors.
>>>   Feel free to propose a new item or comment under an existing one. I
>>> expect to start gradually updating the page beginning of Feb.
>>> -- Vassil
>>> [1]
>>> https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

More information about the llvm-dev mailing list