similar to: [LLVMdev] malloc, magic, and embedded compilation

> 1. The particular optimization that was done there was based on the > compiler substituting an alternate implementation of malloc(). This may > not be appropriate in kernel or deeply embedded systems. Is there a way > for someone who is building that sort of system to enable/disable the > builtin library magic selectively? -ffreestanding > I assume that LLVM can support

On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote: > I don't think the logic is based on "main", but on whether functions > are marked "internal" or not. That said, GlobalOpt.cpp seems to reason > based on the name "main" (most likely bogus, because of constructors/ > destructors running before main). Umm. That sounds like a test case that really

On Wed, 14 May 2008, Jonathan S. Shapiro wrote: > On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote: >> I don't think the logic is based on "main", but on whether functions >> are marked "internal" or not. That said, GlobalOpt.cpp seems to reason >> based on the name "main" (most likely bogus, because of constructors/ >> destructors

(summarising IRC) Rethinking a little, I would be inclined to agree that combined hosted and freestanding modules should not be compiled in hosted mode. Here's one scenario where we may break: suppose I LTO-link an implementation of memset compiled with -ffreestanding with a program compiled with -fhosted. With the proposed rule, the loop idiom recognizer may transform the body of the memset

On Wed, 2008-05-14 at 10:20 -0700, Chris Lattner wrote: > On Wed, 14 May 2008, Jonathan S. Shapiro wrote: > > On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote: > >> I don't think the logic is based on "main", but on whether functions > >> are marked "internal" or not. That said, GlobalOpt.cpp seems to reason > >> based on the name

On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote: > >> How does this affect freestanding implementations? > > This transform is disabled with -fno-builtin or -ffreestanding. Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is

One more question on this. The substitution of malloc() is predicated on the assumption that the compiler knows the implementation of malloc(), and the argument for that seems to rest in part on the specification of the Standard C Library. But I am not aware of any requirement that compliant C code must be linked with the Standard C Library. If this requirement does not exist, then no portion of

On Wed, 14 May 2008, Jonathan S. Shapiro wrote: >> huh? > > Duncan asserted that there is a behavior in GlobalOpt.cpp that relies on > main being the single entry point. If he is mistaken, great. If he is > correct, a regression test case for this seems like a useful thing to > build. I'm not saying that somebody else should do it. In fact, it seems > like a fine way to

On Wed, 2008-05-14 at 14:38 -0700, Chris Lattner wrote: > On Wed, 14 May 2008, Jonathan S. Shapiro wrote: > >> huh? > > > > Duncan asserted that there is a behavior in GlobalOpt.cpp that relies on > > main being the single entry point. If he is mistaken, great. If he is > > correct, a regression test case for this seems like a useful thing to > > build.

+Eric and Akira (for thoughts on module flags) > On 2016-Sep-16, at 12:47, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Sep 16, 2016, at 12:30 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> In PR30403 we've been discussing how to encode -ffreestanding when using LTO. This bit is currently dropped during LTO because its only

New clang versions need the '-ffreestanding' flag because new changes convert system calls to their unlocked versions, which don't exist in the kernel library. Signed-off-by: Bill Wendling <morbo at google.com> diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc index f500d535..9cf4b2d9 100644 --- a/scripts/Kbuild.klibc +++ b/scripts/Kbuild.klibc @@ -67,7 +67,8 @@ include

In PR30403 we've been discussing how to encode -ffreestanding when using LTO. This bit is currently dropped during LTO because its only representation is in the TargetLibraryInfo created by clang ( http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258). The proposal is to introduce a module flag that we set in any translation unit compiled in hosted (i.e. -fno-freestanding)

Hi Sean On Sun, Feb 26, 2017 at 5:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > For that triple, Clang seems to be calling into GCC driver > (/usr/bin/arm-none-eabi-gcc) for linking and GCC doesn't recognize > -fuse-ld=lld (supposedly -fuse-ld=gold selects ld.gold, -fuse-ld=bfd > selects ld.bfd and you would expect -fuse-lld=lld to select ld.lld, but it >

On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>>>> -ffreestanding >>>>> > with no success. >>>>> clang (as well as gcc) requires that freestanding environment provides >>>>> memcpy, memmove, memset and memcmp.

On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: >> >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com> >> wrote: >>>>>>> >>>>>>> > How do I disable that feature? I've

On Tue, May 29, 2012 at 9:16 PM, Chandler Carruth <chandlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>> -ffreestanding >>> > with no success. >>> clang (as well as gcc) requires that freestanding environment provides >>> memcpy, memmove, memset and memcmp. >>> >>> PS: Consider

On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> > How do I disable that feature? I've tried -fno-builtin and/or >>>>>> -ffreestanding >>>>>> > with no success. >>>>>> clang (as well as gcc)

On Tue, May 29, 2012 at 8:46 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > How do I disable that feature? I've tried -fno-builtin and/or > -ffreestanding > > with no success. > clang (as well as gcc) requires that freestanding environment provides > memcpy, memmove, memset and memcmp. > > PS: Consider emailing cfedev, not llvmdev. > Hi,

Even with -ffreestanding LLVM generates memcpy/memset? Does this mean some passes do not honor this flag? If you really wanted to prevent libcalls, you could technically translate those memcpy/memset to loops in lowering. Kevin On Sat, Oct 15, 2016 at 4:10 PM, Wolfgang McSneed via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi and Joerg, > > Thanks for your fast

On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <jyasskin at googlers.com>wrote: > On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> > wrote: > >> > >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com >