search for: intiializer

> > Cool. This then makes your other point about requiring LLVM tools less of > an issue because the out-of-tree builds can use whatever tools you choose. > We just need to make the builtins work so that you don’t need them already > built. With that in mind for an intiial solution before you get to stripping out the cmake stuff so that it can do an out of tree bootstrap. I have

> > I will not be stripping out any of the existing CMake. If we go down this > path what I’m going to do is refactor the CMake to produce to logically > separated projects so that the builtins can be built with or without the > runtime libraries. It will all still be CMake-based. Sorry. s/stripping/seperating/g I was still thinking about the stripping of the IOS build from the OSX

I am interested in starting a project to port stable versions of OpenSSH to C#, compilable as a stable .Net Library. I was wondering what the list's feelings would be on such a port, if any one else would be interested in such a port, and for any suggestions on raising interest from others to perform such a port. I have nothing against Java and would welcome a similar effort from that arena.

On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at gmail.com> wrote: > Just as a point for building the builtins shouldn't we just need llvm-ar ? Thanks for pointing this out and I hope llvm-ar is up to the task. Even if targets must still port binutils, each step toward LLVM self-reliance is a step in the right direction. Without getting too far ahead of ourselves,

...ues for each primitive type, >and pointer type. Consequently, there was no need to write these to the >bytecode file any more. In some cases, this saved huge amounts of bytecode >because zero initializers for large arrays of primitive type initialized >to zero caused emitting a zero intiializer for every element of the array. >THis is no longer done. > >>You might want to make this clearer when talking about values in the body >>of the document. > >Could you suggest how? I'm a little fuzzy on what you're getting at here. It could be mentioned in the val...

...t;null" values for each primitive type, and pointer type. Consequently, there was no need to write these to the bytecode file any more. In some cases, this saved huge amounts of bytecode because zero initializers for large arrays of primitive type initialized to zero caused emitting a zero intiializer for every element of the array. THis is no longer done. > You might want to make this clearer when talking > about values in the body of the document. Could you suggest how? I'm a little fuzzy on what you're getting at here. > --> A comment on this: if a value of zero were...

Reid, Thanks for the detailed feedback. A value of zero now means zero literal for everything except labels, right? There is kind of a vague reference to this in the 1.0 -> 1.1 section I believe. You might want to make this clearer when talking about values in the body of the document. --> A comment on this: if a value of zero were never used for labels, that would make me happy,