search for: getfoo

Hi, I am trying to figure a way to allocate a string SEXP so that gc() won't ever collect it. Here is a little bit of a background. Suppose I want to write a .Call-callable function that upon each call returns the same value, say mkChar("foo"): SEXP getFoo() { return mkChar("foo"); } The above implementation doesn't take advantage of the fact that mkChar("foo") could be pre-computed only once, and then the function would return the pre-computed value. So the question is how to create this precomputed value. The closes...

On Mar 3, 2014, at 12:04 AM, Chandler Carruth <chandlerc at google.com> wrote: >> I was actually going to check in this, but I can post it for review if folks are worried. >> >> My plan was to provide an implementation of std::iterator_range<T> and then provide 'F.arguments()' which returns it. > > Nice. What's the logic behind .arguments() vs

> On 24 May 2018, at 20:19, Sam McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The coding guidelines say: > > Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). > > This means that functions that

On 24.05.2018 13:11, Dean Michael Berris via llvm-dev wrote: > >> On 24 May 2018, at 20:19, Sam McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> The coding guidelines say: >>> Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case

The coding guidelines say: > Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). This means that functions that just compute or access a value (no side-effects) should be named e.g. `getParent()`, rather than `parent()` as they are in

...justment. This looks like the opposite: it is making room for passing a parameter to the next call (the stack grows downwards). But you put me on the right track. The problem is that the class is returned on the stack. This is the class: class Foo { public: Foo() : data(113.5) {} static Foo GetFoo() { return Foo(); } private: double data; }; This is the assembler code for Foo::GetFoo: Dump of assembler code for function _ZN3Foo6GetFooEv: 0x6e08b5a4 <_ZN3Foo6GetFooEv+0>: push %ebp 0x6e08b5a5 <_ZN3Foo6GetFooEv+1>: mov %esp,%ebp 0x6e08b5a7 <_ZN3Foo6GetFooEv...

Hi, > define internal i1 @Addr_045442A0() { > alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] > alloca i1, align 4 ; <i1*>:2 [#uses=2] > tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) this call uses the "struct-return" convention (due to the sret attribute). On x86 this means that the caller is responsible for adjusting the stack pointer after

a static local still produces a static dtor, though One of the ways you can get around this is with a deliberate non-cleanup: const foo &getFoo() { static const foo &f = *new foo(); return f; } that way no global dtor runs. Obviously only works if you don't need foo's dtor to run. On Tue, Mar 8, 2016 at 11:42 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I believe the rule is only for glob...

...0x17> > 00000103: IMAGE_REL_I386_REL32 _setfoo > 107: c3 retl > 108: 0f 1f 84 00 00 00 00 00 nopl (%eax,%eax) > 110: 00 00 addb %al, (%eax) > 00000110: IMAGE_REL_I386_DIR32 _XEP:getfoo > 112: 00 00 addb %al, (%eax) > > _getfoo: > 114: 50 pushl %eax > 115: 89 e0 movl %esp, %eax > 117: c7 00 00 00 00 00 movl $0, (%eax) > 00000119: IMAGE_REL_I386_DIR32 _foo > 1...

...00000103: IMAGE_REL_I386_REL32 _setfoo >>> 107: c3 retl >>> 108: 0f 1f 84 00 00 00 00 00 nopl (%eax,%eax) >>> 110: 00 00 addb %al, (%eax) >>> 00000110: IMAGE_REL_I386_DIR32 _XEP:getfoo >>> 112: 00 00 addb %al, (%eax) >>> >>> _getfoo: >>> 114: 50 pushl %eax >>> 115: 89 e0 movl %esp, %eax >>> 117: c7 00 00 00 00 00 movl $0, (%eax) >>>...

...o correct for that. I'm pretty sure that's exactly what this sub is doing. > But you put me on the right track. The problem is that the class is > returned on the stack. > > This is the class: > > class Foo { > public: > Foo() : data(113.5) {} > static Foo GetFoo() { return Foo(); } > private: > double data; > }; > > This is the assembler code for Foo::GetFoo: > > Dump of assembler code for function _ZN3Foo6GetFooEv: > 0x6e08b5a4 <_ZN3Foo6GetFooEv+0>: push %ebp > 0x6e08b5a5 <_ZN3Foo6GetFooEv+1>: mov...

...initial pain the result is much cleaner APIs. For trivial changes, where someone decides to change the spelling of a method because the old one didn't meet some convention (I've lost count of the number of times this has happened), it means that now you get a compiler warning saying 'getfoo() is deprecated, use getFoo() instead', rather than a 'getfoo() doesn't exist, go and read the docs (if they exist) to find out what it is called this week'. > 2. Use stable releases, only core developers work on trunk > - Changes are big, infrequent > 2.a No API chang...

When my llvm code calls certain function, either it receives a wrong result or the application ends on what it seems a corrupt stack. The function is a C++ static method that returns a class with just a `double' data member: class Foo { double data; }; My compiler abstracts this as a [8 x i8] array. This is the llvm code: define internal i1 @Addr_045442A0() { alloca [8 x i8], align 4 ;

...- The patch doesn't have a consistent newline convention, it is a mix of DOS and Unix. - if( -> if ( - A [1] -> A[1] - Braces go on the same line as if/else. - Please use AddFragment instead of add_fragment, etc, and we tend to only use a leading lower case for accessor methods (getFoo) or trivial inlines functions, but not for methods which do work or have substantial side effects. - Please use complete sentences in comments, i.e. capitalized and ending with proper punctuation. - Please don't use an extra newline following 'for' loops, conditionals, or type decla...

...t is worse :-) > > On Wed, Mar 9, 2016 at 10:49 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> a static local still produces a static dtor, though >> >> One of the ways you can get around this is with a deliberate non-cleanup: >> >> const foo &getFoo() { >> static const foo &f = *new foo(); >> return f; >> } >> >> that way no global dtor runs. Obviously only works if you don't need >> foo's dtor to run. >> >> On Tue, Mar 8, 2016 at 11:42 PM, Craig Topper via llvm-dev < >>...

On Mon, Jun 5, 2017 at 1:34 PM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > Uh. Turns out that if I hide the pointer to @foo from LLVM by passing it > through an opaque identity function ... then everything works fine. > > Is this a bug in LLVM or is there some magic involving globals I'm > misunderstanding? > This looks like a bug in the handling of

...rongly that these functions should be returning the builder? What I would like to do is either replace and complete the current set of buildOpcode functions with ones which return the output register value, or add an alternative set which do. Is it worth having two sets of functions (a buildFoo and getFoo set?). The same issue applies with opcodes producing multiple results, such as buildUnmerge, but in that case I would probably change these to a SmallVectorImpl out argument. Another minor issue I’ve run into is when trying to add convenience functions with constants (e.g. shift creation with mate...

I have updated my patch based on Chris'es feedback. I removed the dbgout_calls macro, but left others in place for now. If there are no objections, I would like to commit this tomorrow evening (~7PM GMT-7). I have compiled and tested it on MSVC, with Michaels testing code and it looks good. Once this is committed, Michaels patch can be applied. -Nathan -------------- next part --------------

On 6 November 2013 11:02, <dag at cray.com> wrote: > Except that there hasn't been warning at all. The only "warning" is > that "we're going to upgrade to some new toolchain." We need to know > *exactly* which toolchain that is so we can test all of our software > against it. "4.7.x" doesn't help because every point release has new

Renato Golin <renato.golin at linaro.org> writes: > I think there are two main problems here: > 1. People use trunk on side-projects because releases mean very little > in LLVM world > 2. We start adding new stuff as soon as a release is branched, and > that reduces warnings up to a few days > > We're all talking about problem 2, when in fact, I think the problem