search for: shaeffer

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 f...

...at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/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

...he canonical 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

...ntil they 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

...of magnitude 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

...ng such a 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

...pressions including side effects during their evaluation, array out of bounds access, etc.). But you are right in that the generated code has some structure ;) Cheers, -moh -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Karen Shaeffer Sent: Monday, June 24, 2013 5:17 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [icFuzz] Help needed with analyzing randomly generated tests that fail on clang 3.4 trunk On Mon, Jun 24, 2013 at 11:20:09PM +0000, Haghighat, Mohammad R wrote: > The tests by design are syntactically correct,...

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

...arching nor exclusionary. I don't think such a CoC would limit reasonable 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

...Linux community sees this is a > disadvantage. Rather, they see it as a way of encouraging developers to > open-source their drivers and have them included in the Linux kernel tree. > I'm not convinced that you'd get buy-in from the Linux community. Your opinion is same as Karen Shaeffer. We cannot upstream all kernel modules source code into mainline, this is not simply a technical problem or community problem, I believe that every company have its own kernel module which cannot upstream, or not worthwhile, if the company is working on kernel module development. upstream kernel mo...

> 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

...sees this is a >> disadvantage. Rather, they see it as a way of encouraging developers to >> open-source their drivers and have them included in the Linux kernel tree. >> I'm not convinced that you'd get buy-in from the Linux community. > Your opinion is same as Karen Shaeffer. > We cannot upstream all kernel modules source code into mainline, this > is not simply a > technical problem or community problem, I believe that every company > have its own > kernel module which cannot upstream, or not worthwhile, if the company > is working > on kernel mod...

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