similar to: [PATCH] kbuild: add -ffreestanding to required flags

Bill Wendling dixit: >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. This is probably wrong, a libc is not, in contrast to a bootloader or kernel, a freestanding environment. For the case of GCC, -ffreestanding is definitely wrong. Please look for another

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

(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

+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

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)

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 >

Hi, I have the following program: // test.c #include <stdlib.h> struct foo_t { int x[1024]; }; __thread struct foo_t g_foo; void bar(struct foo_t* foo) { g_foo = *foo; } int main() { struct foo_t* f = (struct foo_t*)malloc(sizeof(struct foo_t)); bar(f); return 0; } When I compile it with clang I see that it inserts memcpy() in function bar(): $ clang -v clang version 3.2 (trunk

On Sat, Oct 15, 2016 at 04:01:36PM -0700, Mehdi Amini via llvm-dev wrote: > > > On Oct 15, 2016, at 3:56 PM, Wolfgang McSneed via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > I am hoping that someone can help me figure out how to prevent the insertion of "memcpy" from the assembly source. > > > > My target is an

The discussion of malloc optimization from two (three?) weeks ago prompts me to be concerned about implications for kernel compilation. Basically, I have two questions: 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

> On Aug 7, 2014, at 4:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > >> I downloaded the latest NDK (r10) and compiled with the following cmd: >> arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0 >> It still produces assembly with a call to "memcpy". Maybe the -fno-builtin >> is broken also in the latest release. >

On Tue, May 29, 2012 at 10:28 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > 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

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 Thu, 2019-02-07 at 20:17 -0800, H. Peter Anvin wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On 2/7/19 1:53 PM, Joakim Tjernlund wrote: > \>>> > > > > -z muldefs would bloat the libraries unnecessarily, but worse it might

> 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