search for: llvmcommits

If cmake happens to detect GCC for the C compiler and Clang for the C++ compiler, then a manual override of either the C compiler or SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening on my Darwin build environments: -- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is Clang 4.1.0 Without the manual overrides, all C sources fail to compile

On Nov 25, 2012, at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Nov 25, 2012 at 3:19 PM, Joe Abbey <jabbey at arxan.com> wrote: >> If cmake happens to detect GCC for the C compiler and Clang for the C++ >> compiler, then a manual override of either the C compiler or >> SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been

On Sun, Nov 25, 2012 at 3:19 PM, Joe Abbey <jabbey at arxan.com> wrote: > If cmake happens to detect GCC for the C compiler and Clang for the C++ > compiler, then a manual override of either the C compiler or > SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening > on my Darwin build environments: > > -- The C compiler identification is GNU 4.2.1 >

I've also been looking at debugging with ELF and noticed the same problem as Renato. I just sent a patch to llvmcommits that fixes the problem. DW_at_stmt_list needs to emit a label(and therefore a relocation) for the offset rather a constant 0, then the linker can fixup the offset as it shuffles object files around. Krister On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at systemcall.org>wrote: &...

On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com> wrote: > I've also been looking at debugging with ELF and noticed the same problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) for the > offset rather a constant 0, then the linker can fixup the offset as it > shuffles object files around. Hi Krister, We've applied your patch locally and it solved our problem, thanks!...

On Sun, Nov 25, 2012 at 3:19 PM, Joe Abbey <jabbey at arxan.com> wrote: > If cmake happens to detect GCC for the C compiler and Clang for the C++ > compiler, then a manual override of either the C compiler or > SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening > on my Darwin build environments: > > -- The C compiler identification is GNU 4.2.1 >

...hey come from explicit calls to ::operator >> new. We cannot work around this in the frontend by marking the call as >> 'nobuiltin' for two reasons: >> >> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >> (see recent patch on llvmcommits) >> 2) We can't block the optimization if the call happens through a function >> pointer, unless we also annotate all calls through function pointers as >> 'nobuiltin' >> >> How feasible would it be to make the 'builtin-ness' of _Znwm etc be >&gt...

...they come from new-expressions, and not if they come from explicit calls to ::operator new. We cannot work around this in the frontend by marking the call as 'nobuiltin' for two reasons: 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other opt...

On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) >> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >> >> How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-o...

On 26 Aug 2010, at 10:32, Krister Wombell wrote: > I've also been looking at debugging with ELF and noticed the same > problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) > for the > offset rather a constant 0, then the linker can fixup the offset as it > shuffles object files around. It's not just DW_at_stmt_list, you have to do the same for the pointer...

...5, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >>>>> (see recent patch on llvmcommits) >>>>> 2) We can't block the optimization if the call happens through a >>>>> function pointer, unless we also annotate all calls through function >>>>> pointers as 'nobuiltin' >>>>> >>>>> How feasible would it b...

...ssions, and not if they come from explicit calls to ::operator > new. We cannot work around this in the frontend by marking the call as > 'nobuiltin' for two reasons: > > 1) The 'nobuiltin' attribute doesn't actually prevent the optimization > (see recent patch on llvmcommits) > 2) We can't block the optimization if the call happens through a function > pointer, unless we also annotate all calls through function pointers as > 'nobuiltin' > > How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in > rather than opt...

...from new-expressions, and not if they come from explicit calls to ::operator new. We cannot work around this in the frontend by marking the call as 'nobuiltin' for two reasons: > > 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) > 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' > > How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there...

...it calls to ::operator >>> new. We cannot work around this in the frontend by marking the call as >>> 'nobuiltin' for two reasons: >>> >>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >>> (see recent patch on llvmcommits) >>> 2) We can't block the optimization if the call happens through a >>> function pointer, unless we also annotate all calls through function >>> pointers as 'nobuiltin' >>> >>> How feasible would it be to make the 'builtin-ness' of...

...or >>>> new. We cannot work around this in the frontend by marking the call as >>>> 'nobuiltin' for two reasons: >>>> >>>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >>>> (see recent patch on llvmcommits) >>>> 2) We can't block the optimization if the call happens through a >>>> function pointer, unless we also annotate all calls through function >>>> pointers as 'nobuiltin' >>>> >>>> How feasible would it be to make the 'b...

Hi all, A discussion was being carried on llvmcommits about the extra time for cleaning and re-building objects that didn't need to be built on buildbots. Since they just update the repository, builds could be a lot faster if we let the objects in place. Even faster if we used Ninja with CMake. Is there a crucial reason why we're still using...

...it calls to ::operator >>> new. We cannot work around this in the frontend by marking the call as >>> 'nobuiltin' for two reasons: >>> >>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >>> (see recent patch on llvmcommits) >>> 2) We can't block the optimization if the call happens through a >>> function pointer, unless we also annotate all calls through function >>> pointers as 'nobuiltin' >>> >>> How feasible would it be to make the 'builtin-ness' of...

...> On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) >>> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >>> >>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rathe...

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering f...

...> On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) >>> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >>> >>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rathe...