search for: neuralscape

...nfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev --- end quoted text --- -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb

Karen Shaeffer <shaeffer at neuralscape.com> writes: > I am also aware of the way too common problem of folks stuck in a time > warp, because they have dependencies on old libraries that they cannot > upgrade. IMO, a development effort should not slow the pace of feature > adoption to support folks who have not planned fo...

...cal kernel and gcc releases. In the case of RedHat, I believe they require you to build the kernel with their tool chain. They will not support any modifications to the build process or the kernel. So, in a situation such as you describe, you are likely on your own. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040

...figure out how to upgrade. I recommend targeting 4.7.2 or later, because all new C++ code on linux is surely going down that path. You can inconvenience the laggards, or you can turn away the folks leading the way with new implementations. But you can't satisfy both. Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040

Hi, Is it possible to link native codes generated by different compiler? the usecase could be: Linux kernel compiled by gcc want to load kernel module compiled by Clang (I know there have some problem to compile kernel by Clang currently, but ignore those problem in here) I just concern about the call conversion problem, and compatibility between gcc and clang. Thanks .jovi

...ude more complex than embedded environments. True linux kernel experts don't even use debuggers. Of course I wish you well with your efforts. But you need to fully grasp the ethos of the linux kernel development community, before you can succeed at such a goal. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040

...tool for a general purpose compiler would be quite a bit more difficult, but it is doable. Imagine releasing compilers that are bug free, at least for a given language and a particular platform. It's doable, and I wonder why corporations don't invest in it. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040

...tool for a general purpose compiler would be quite a bit more difficult, but it is doable. Imagine releasing compilers that are bug free, at least for a given language and a particular platform. It's doable, and I wonder why corporations don't invest in it. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040 _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

The tests by design are syntactically correct, semantically correct, and have deterministic output. -moh From: Nick Lewycky [mailto:nlewycky at google.com] Sent: Monday, June 24, 2013 4:14 PM To: Haghighat, Mohammad R Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [icFuzz] Help needed with analyzing randomly generated tests that fail on clang 3.4 trunk On 24 June 2013 16:10, Haghighat,

On Mon, Apr 29, 2013 at 3:11 PM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Just out of curiosity, what would be the main benefit of this approach vs DKMS which is already widely used ? > Thanks Dupas. I checked DKMS you mentioned, basically DKMS is just a ko and its sources management tool. It's not easy to deploy ko source into target machine, and it's more

On Jan 8, 2013, at 4:24 PM, dag at cray.com wrote: > I am personally very much in favor of this. C++11 really is a huge leap > from C++03 in terms of readability, maintainability and safety. I agree completely. > Why not C++11 libraries? Implementation/capatability reasons? I don't > know anything about how the various implementation compare in terms of > completeness. But

> I've obviously being playing with C++ too long because my > instinct immediately told me that dynamically sized arrays on the > stack are't allowed but apparently that's fine for C99 (g++ also seems > fine with this is you don't specify -pedantic) It's all fun and games until someone decides to evaluate sizeof(arr). ;-) I think a more limited form is coming to

...nable expression on this list nor more generally in the LLVM community in any way. And it clearly invites all individuals to feel welcome. I'm trying to understand what your specific objections are. thanks, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb

On 02/05/2013 03:58 PM, Chandler Carruth wrote: > On Tue, Feb 5, 2013 at 3:50 PM, Preston Briggs <preston.briggs at gmail.com > <mailto:preston.briggs at gmail.com>> wrote: > > The MBlaze backend seems to be essentially unmaintained since > 2011. The maintainer (Wesley Peck who is BCC'ed) seems to have > vanished, and in fact all emails to

Thanks for the reply. Please see my inline responses. On 15/08/13 12:58, Tim Northover wrote: > Hi Dan, > >> It is not stated how the "<ty>" type is used as we are told the >> type of result is type* and sizeof(<type>)*NumElements is the >> amount of memory so from my perspective it looks like <ty> is >> never used which would seem to

Can someone confirm whether the following is a known clang bug? I am having a lot of trouble compiling some old legacy code due to this error. I know "using namespace" is horrible but that doesn't make it illegal (g++ accepts this). The fix is easy but there are just too many instances of this in the legacy code. The following is not from the code I am trying to compile but is

Am 05.05.2016 um 23:19 schrieb Tanya Lattner: > Having a code of conduct like this is just as bad as having no code > of conduct at all. It trivializes the importance of a code of conduct > and its pretty much impossible to enforce. Regardless of what kind CoC you have: if it comes to having to enforce it, the community has stopped being open and welcoming. So I think this approach is

On Tue, Oct 13, 2015 at 11:16 AM Renato Golin <renato.golin at linaro.org> wrote: > On 13 October 2015 at 18:59, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > We have *not* appointed any such committee at this point. > > (...) > > The appeal is to the board of the Foundation. I don't expect the board to > > *be* the committee

Hello all, Using the Apache Wiki [1] I summed up what can be used simultaneously by gcc, MSVC and clang. I mostly considered only the latest versions of the proposals where there were several, where not there is a link to a note at the bottom. Furthermore I did not scourge through 3 bug databases and I implicitly trusted the wiki page. I drew up a list of profiles, listing the base

On 13 October 2015 at 16:41, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: >> - *Be welcoming.* We strive to be a community that welcomes and supports >> people of all backgrounds and identities. This includes, but is not limited >> to members of any race, ethnicity, culture, national origin, colour, >> immigration status, social and economic class, educational